Most of the overhead in virtualisation of the sort used by WSL2+ is not CPU throughput, but other hardware access (mostly IO, but for GUI apps display access can have a significant penalty). Things that are just spinning a couple of CPU cores doing number-crunching work and similar see significantly less penalty in VMs than those that perform much IO, unless of course there is much competition for host resources or for some other reason they get passed around cores so see many more L1 cache & TLB misses.

Some things need to max out the CPU, certain compile steps for instance, that is not slop that is code doing its job. Others need significant IO, often random IO, certain other compile/link steps for example, that is not slop. Sometimes if you knew your code was likely to be run in a VM rather than on bare metal you might design it slightly differently to reduce its sensitivity to the detrimental effects, but not having done so doesn't make your code slop. There might be some room to blame slop for UI slowness as a lot of code out there updates their display in an in inefficient manner that is actually noticeable on bare metal too, especially when it unnecessarily uses 3D accelerated compositing or similar and something causes that to fall back to software rendering, but even then if it works well enough in the intended environment calling it slop is perhaps unfair.