In general a linker could parallelize the reading of the object files. Most everything else is probably too serialized...
The async callbacks provided by the Windows (originally OS/2) API might arguably favour heavy multithreading in a way that the unix API doesn't. Or it might be that the MSVC linker actually suffers from being written as a multithreaded program and /demands/ lots of CPUs/cores.
As a potential point of debate, I'd suggest that an OS should or at least could throw spare CPUs/cores at the job of keeping the various buffers and caches needed by the linker full. In any event, sooner or later one hits the limit of how much traffic can pass through the kernel down to a small number of physical storage devices accessed via a small number of busses.
Of course, if one looks at one of the most frequently examined cases that can benefit from make -j, i.e. a Linux kernel rebuild, one notices that most of the code- i.e. almost all the drivers etc.- is saved in the form of .ko files. Multiple .ko files are definitely built in parallel, but I don't know to what extent the fairly small number of intermediate files which are linked to build a .ko are built in parallel.
If OP wants to make a case for change, then I think he needs to provide convincing evidence that an individual Linux .ko benefits from parallelisation, and then demonstrate that FPC's building an individual package is significantly less efficient... which together would be a fairly hefty analysis job, allowing for the number of .ko files and packages being built simultaneously.
And in any event, he'd have to demonstrate that any change was both compatible with fpcmake (which is central to the wide variety of targets FPC supports) and with things like generics.
MarkMLl