In terms of speed, at least when we look at mostly single-threaded work load (like most dev work is), a M2 Macbook Air is faster than every Desktop PC. Correct me if I'm wrong.
Eh. The 12900k still has the edge in most single threaded benchmarks, and the latest Threadripper Pro will easily crush it on multithreaded loads (all while drawing close to an order of magnitude more power). Also your MacBook Air will thermal throttle if under load for too long, while a desktop computer offers a lot more options for cooling. Further more a desktop computer gives you the option to use faster storage and more and faster RAM which might be very relevant in some scenarios. Plus there is the whole GPU/CUDA side of things which may or may not be relevant to you.
All that being said, I'm typing this on an M1 MBP and the perceived day to day performance is better than any desktop computer I've owned, even if it will no doubt lose out a 'real' workstation when it comes to running 24 hour CFD simulations.
I suspect that if I crank my I/O subsystem to do flushes no more often than once in 40 seconds and lie to fsync/fdatasync, my Threadripper setup is also going to run circles around my M2 Air. (Heck, I suspect my XPS13 will be almost on par.)
But then again, the M2 Air has this bulky UPS called „laptop battery”, so they can afford such little lies as long as the OS itself won’t shit itself and die randomly. Granted, it happens rarely, but nevertheless.
For instance, when you send a message from the backend container to the database container during ordinary CRUD, the backend container will largely be waiting for the database to start processing. Something similar for most frontend requests - usually in dev work, you press a button, it sends an API request and awaits the response; the API request sends a message to the database and blocks on the response. The database sits around idly waiting till it receives a message, and sends something back. Then the backend postprocesses the reply and produces the response, and then the frontend postprocesses the response. There is some degree of joint action during the actual communication phases but it wouldn't put a huge load on the multithreading capacity of your CPU.
Something similar can be said for Gitlab/Slack/Email - in the background, they could easily be using the spare CPU time rather than competing for time, and you wouldn't actually notice it. But they also should spend most of their time waiting around doing nothing.
So I think the claim is specifically true for some stacks with poor test coverage.
But if you have compiled code, it should probably be compilable in parallel (and if it isn't, you should be complaining to the compiler writer and/or refactoring your code). Likewise, unit tests should in practice be runnable in parallel - if they are not, they're probably closer to integration tests. Even integration tests should be writable so that they can run in parallel, because you hope to have more than one user acting in parallel. And you generally shouldn't be testing your feature development manually. Even if you prefer to visualise your process, you can code it up in something like cypress so that you can run them later or check up why you missed this special case when the bug reports come in.
So I disagree with the original assertion, but I don't think you've provided an effective counterargument.
All that being said, I'm typing this on an M1 MBP and the perceived day to day performance is better than any desktop computer I've owned, even if it will no doubt lose out a 'real' workstation when it comes to running 24 hour CFD simulations.