"Complaining that memory usage grew by a factor of one thousand when a (portable!) machine that's more than an order of magnitude cheaper has four million times more memory seems a bit ridiculous."

Consider a different user from the the author who is designing a system where memory is the filesystem. "Disk" space is memory. The more "disk" a program occupies, the less memory available for everything else. (The same is true for non-memory backed storage space.)

For this user, the complaint is not ridiculous at all. BusyBox commands do not have the full range of command line options. NetBSD has versions of common utilties that have reduced options, intended to be used on small-sized and/or memory-backed filesystems. There are many examples.

The idea that today's computers have more memory/storage and therefore today's programs should be larger does not make sense if the user intended to use the increased memory/storage for something other than programs. Purchasing computers over a few decades with increases in resources for the same price ("bigger bang for the same buck"), the purchaser might expect an increase in the ratio of (a) memory or storage used by others' programs to (b) free memory or storage she can use for her own things. When the size and memory usage of software not written by the computer purchaser increases because of the increased availablity of storage and memory, then that takes away those resources from use by other things. Who do the resources belong to, who paid for them, and who should have the final say in how they are used.

For example, consider programs the computer owner has written or wishes to write or files she wishes to store. Less resources are available for/to those things because someone else thinks that the bigger bang the purchaser is getting for her buck is not entirely the purchaser's. It belongs to anyone who can write programs. Under this theory, the purchaser does not get to decide the quantity of resources other programmers get to use. Other programmers declare they should be unconstrained to use as much resources as they think they need. There is more memory and storage thus they get to use it. Yet those programmers did not pay for that increased storage and memory. The computer purchaser did.

How dare a user complain that a program grew by a factor of 1000. The computer has more resources. Therefore anyone can use them. Except the resources do not belong to anyone else besides the person who purchased the computer. Who should get to decide how they are used.

McIlroy is just telling it like it is, it is strange that younger people today want to "disagree". Bloat is bloat. More resources does not make bloat cease to exist as a concept. If someone is eating too much food (more than their body requires), then the availability of more food does not change the fact they are eating too much. Not to mention when someone else is paying for it. "There is so much food available. I am only eating a tiny proportion of what is available. Therefore, I am not eating too much." Statements like "We were doing X in the 1970's" when the author was not even born or yet to have fully formed adult mind by the 1970's are peculiar. Is "we" the appropriate word. "They" were different people.

IIRC, McIlroy once said something like, "The hero is the negative coder." Bloat has become so pervasive that IMO such coders really are heros, maybe not to other programmers, but to this user for sure. Write enormous, complex programs with 50+ options, have fun, be "productive", enjoy convenience and resource abundance, but trying to "disagree" with McIlroy's (accurate) observations is quite silly.

For a user who only uses 20% of the commandline options of a program, the code and resulting size increase correspending to the other 80% of options she never uses is perhaps something to consider, especially when this applies to a large number of programs. The shell can keep track of utility usage so one can see which programs she is using the most and which programs she does not need. Perhaps it would be useful to measure options usage so she can assess what options are used the most and which options she does not need. Ideally unutilised options might be disabled at compile-time.