Is your test mostly waiting on a mechanical hard drive? If so, then "2.5x slower than cp" could mean "a very large amount slower than cp" once you remove that overhead.
Whereas I have not done your specific test, I know that for the file sizes of executables I deal with in everyday work (around 10MB), the amount of time I wait for linking is woefully disproportionate.
For a comparison, an optimized release build of Clang 5.0 trunk (from a few days ago, built with Clang 5.0 trunk from like a week ago) with assertions enabled is 87mb -- with the LLVM libraries linked in, but dynamically linked to system libraries, on my Fedora 25 machine.
A debug build of clang is normally hundreds of megabytes (~600mb IIRC, and normal linkers go bonkers dealing with it), so if LLD is actually only 2.5x slower than 'cp' at -O0, that's quite good I think.
The next question is how much memory LLD uses vs the competition in this test...
It'd be interesting to see the numbers of a ramdisk cp/link as well. With ssd being so much faster than mechanical disks, people sometimes forget that ram is faster still.
Whereas I have not done your specific test, I know that for the file sizes of executables I deal with in everyday work (around 10MB), the amount of time I wait for linking is woefully disproportionate.