Adding features to a code means it was incomplete. Misunderstanding input/output usually means it is poorly documented or lacked a good API. A good API works at the surface (in/out) and not in the volume.
Really good code solves a problem completely. I have worked with such code and yes almost nobody ever goes into this code (and makes changes).
In practice this isn't true. The code may have been perfect and complete according to the business requirements of 1 month ago. But the business requirements of 1 month ago and today are often completely different.
That definitely implies code can't be good if needs change, which makes no sense to me.
eg someone releases a new file format. You believe ffmpeg is bad code?
In ffmpeg case I assume this is how it would be.
Your approach is I guess valid for self contained algorithmic code, i.e. 0.000001% of code out there.
This does not impact readability or the idea of "good code" in my opinion.
You could have an application that is missing features which still contains examples of "good code". Learning about "good code" by reading the source code of this application won't really give any direct hints of missing features...the granularity is different.
Is it not waterfall enough? Is it too much learning from customers? Is it too small PRs of duration less than 1-6 months? Is it not enough premature optimization?