IMO it's a bit more nuanced than what the author portrays it as. Broadly, software used to be much worse on the micro-level but better on the macro-level i.e. architecture.

Since it was much harder to make stuff, you really had to architect it well or otherwise it would simply fall apart. For example in assembler you need discipline in your calling conventions, layout and so on, otherwise it just corrupted, you needed to follow sensible naming conventions otherwise it degenerated into unreadable label spaghetti and so on.

Nowadays it's the other way around, the micro level is so much better due to libraries, code reuse, LLMs and better languages/tools, you can use highly sophisticated data structures and functions at your fingertips. In exchange, you can afford to skimp on architecture because computers are fast anyway, and the programming languages don't let you make a huge mess. (Most don't have unstructured goto/jumps, can't corrupt memory accidentally, etc.)

However, this has the cost of making larger programs a nightmare to maintain and systems suffering from a "death of thousand cuts" i.e. on the micro level all is well but when you look at the entire system it's a sprawling unreliable mess. This is where rewrites often happen ;)

Architecture is still important for large systems. And there are tons of legacy systems with spaghetti code.

Counterpoint - lots of old systems have atrocious architectures.

Those downsides existed, but then that’s just how lots of stuff is or was.

Larger systems are not imo any worse to manage now, but the scale of what is possible and expected dramatically changes what we consider a large system these days.

I think this is like looking back at a few hits and being nostalgic for some decade of music forgetting all the terrible songs of the time. Or perhaps if the volume has increased seeing on YouTube all the school bands that you’d never have seen before because recording was expensive and distribution reserved for the very few.