That was indeed the thrust of the analogy. Basically, we try to design programming languages so that the interface is decoupled from the implementation. A function should have an intuitive, descriptive name that reflects what it achieves, free of such terrestrial concerns as who wrote it, and when, and whether a different person decided to fix a bunch of bugs in it. But commands in Unix exist in a single-layer, permanently immutable namespace. Someone wrote the canonical 'top' once upon a time and now all evolutions on the concept must use names like "htop" and "vtop" and "gtop" and "ptop". By 2121 we'll have exhausted that namespace too, and be on to "aatop", "abtop" etc.
Good interface design is stable, even as the backend tech improves. Both a go-kart and the NASA crawler-transporter have steering wheels, because the wheel is an affordance for the human, not the machine. But on a Unix system, there's huge churn in how to do things - usually for no better reason than that it would break a bunch of stuff to change how the old way works, so better to simply add a new way. Someone wrote an improved version of grep - does that mean we get grep v2? Nope, we get "ripgrep", and old grep stays permanently...
The worst of it is, that namespace doesn't even guarantee anything! It would at least be some consolation if 'ls' worked identically on every system, but alas...