Regressed badly, actually.
Any professional software-writer today writes code that takes several times the memory to do what a programmer would have written 30 years ago to do exactly the same things.
A small part of that is the memory word size.
Most of those old computers used either a 4 bit or an 8-bit word.
Most modern computers use a 16-bit or 32-bit word.
WHen one writes a program for a 4-bit-per-instruction 8-bit address, instructions range from 4 to 12 bits each. on an 8-bit word, that same instruction is 8 or 16 bits.
That very same code on a compatible 64 bit computer using 64bit words is 64 or 128 bits per instruction.
Add to that that some newer processors have 3-word instructions in the set as well, allowing direct memory access rather than just Register+Address commands.
But, yeah, there is a lot of needless code bloat. Monolithic kernels. Lots of bound in but little used protocols. Binding in whole libraries for one or two functions. Large collection libraries instead of more-but-smaller libraries.
Truth be told, I'd love a version of Win 3.1 and MS-DOS 6.22 ported to 32-bit processing... the pure control it allowed was awesome, and with a 32 bit memory address instead of 16 bit... and no artificial 640K limit... it could be really freaking awesome. And bloody fast. Heck, DOS-Box runs games too fast on my mac for some of the DOS games... and that's a VM solution.
Back before OSX, many mac applications were smaller than their windows counterparts, despite nearly identical non-HI† source code... because the HI code was so much smaller and relied upon calls to the ROM rather than binding in the specific HI elements. Same for PalmOS programs under PalmOS 3 & 4; smaller even than MacOSX.
Until we hit a severe limitation on code size again, we won't see a return to tightly optimized and minimized code. And with the current systems, until we get 3d HI code or a demand for natural language interfaces, we're unlikely to hit that optimization need.
† HI=Human Interface