Right, compilers are pretty damn good these days and we've learned a lot of tricks from people who write assembly. However, compilers are not AI and will invariably do things that are less than optimal in some cases. It's not really feasible to write large codebases in assembly, nor are the gains generally worth the effort. My point is simply that when I was first learning to code in the 90s the guys writing assembly were mocking the kids writing C and C++ for writing bloated software with tons of unnecessary dependencies.
Fast forward to today, and a simple CRUD app on your phone is 3Gb just to fill in a form with a button, not counting the backend. I do a lot of data pipeline development where much of the base infrastructure was designed by guys currently in their 20s before I got to the company, and even 10 relatively simple unit tests take 5-10 minutes to run on a modern CPU with plenty of ram(they spin up postgresql/fastapi/moto docker containers). I can't exactly argue that the approach is wrong, but the bloat is EASILY 1000X what I would have created in a clean room just for unit tests. The actual services themselves(that are mocked for the unit tests) handle bursty loads of a few hundred thousand requests per minute, but require a cluster to run. The waste is absurd, but the cost is acceptable to the company. The developers at my company are relatively competent and cost conscious, probably because they're in their late 20s and early 30s and learned to code in a pre-cloud-dominance era.