A linker script typically defines the memory resources available on the platform, which for embedded systems is application specific and not known to the toolchain.
Moreover in a bare-metal embedded system, the linker must both link and locate the code at build time, while in a hosted system executable object file, data and code will have segment identifiers, that are used by the operating system loader to locate the code/data appropriately when the program is launched. So in that case the linker need have no knowledge of available memory resources, as that is dealt with by the OS loader.
So in an embedded system, the linker performs both inter-module reference resolution (link) and explicit memory location (locate), and it is the latter that requires knowledge of the memory layout. In a hosted system, the static linker performs the link stage only, and location is handled by the OS (in a modern desktop OS that environment is also normally 'virtualised').
None of that means that in a desktop system there is no linker script. In Linux/gnu on x86 64bit for example you will find /lib/x86_64-linux-gnu/ldscripts
, where the actual script applied I believe depends on switches passed to the toolchain on build. (Ref Actual default linker script and settings gcc uses).