It's rarely only a question of just allocating money to more/better hardware, it's also a question of policy and willingness of your organisation to keep CI time short/feedback fast.
Also my local machine has resources entirely dedicated to me and isn't held back because someone else decided to rebuild the world.
Scale up ahead of time, so there’s always a machine ready. Prefetch the repository / packages when CI workers start, so they’re already installed before a build is triggered. Use your imagination - CI doesn’t have to suck.
If you're paying for an engineering team, that's a rounding error.
I don't think is has to end like that. You can have separate queues and separate levels of assurance. For example, does every commit have to be tested in each of 20 possible configs? You can run one common config by default and allow unblocking the rest on demand. Then enforce all of them only as a merge gate.
If you can also split them into separate queues that don't block each other, you get both larger matrix and faster dev turnaround.
So you do need policies to actually be allowed to optimise CI.
Effort and money will only be expended to make things faster when the build times are perceived as intolerable.
It's great for keeping things tidy and not having to break the whole thing up in modules like "UI 21.0.12.11 needs Backend 12.2.1.11 or greater". Instead everything builds more or less into a monolith. But it does have one drawback: making a commit invalidates every bit of the build output immediately.
While largely fixed now, older C# projects suffered from separating dll references from the reference to the package that provided them.
This lead to the situation where you may be referencing a package that hasn't been downloaded. Due to the package cache, the solution would typically build on a "dirty" environment like the developer's machine or anything that had previously built the project but would fail on any fresh environment.