Lean is not a software development methodology. It is made for factories and production lines, a terrible fit for most kinds of software. The only salvageable parts from it is iteration and listening to frontline workers to get process improvements.
"Autonomation"/Poke Yoke as in automated tests.
Which is not enough of a methodology.
The "Lean for software" page gives contradictory definition of waste - you're supposed to minimize defects while at the same time minimizing rework. I'd like a crystal ball that enables it. Plus you cannot apply it without absolute control over the whole development process. Any place that is a black box (say, both set of features and deadlines are given) the process. Thus it fails in corporate environment.
Likewise, general agile methodologies are easily perverted into what I just described - by skipping refactoring and redesign parts in service of deadlines.
That model works only if you throw things away like startups do or the project is small and self-contained.
Usually small projects are low value or grow big. C.f. Twitter or YouTube when it started and now. Even worse if you get to interact with quickly changing parts controlled by another team you do not control in even a medium sized project.
It also doesn't attempt to minimise rework (it values iterative approaches), and is strong on exploratory prototypes.
Again, I think what you're criticising is "Agile as implemented in dysfunctional organisations" rather than actual Agile.
I'm building a startup, though. My definition of "good" software is probably different to yours (and that's as it should be).