The point at which new changes are more likely to degrade an application that's already excellent for its established use cases than they are to improve it further is the point at which we should consider the software "finished".
There may be lots of theoretically plausible improvements that could be made, but if the constraints of actual practice make pursuing those ideas a net detriment, that's probably a good place to stop.
I think AI may actually make this simultaneously better and worse: it will eventually be really easy to hit all of the functional and performance targets early on, so "finished" software will at some point be much better and closer to true completion, but the mentality that drives people to keep fiddling with it instead of moving on to a new project will be just as prevalent, and the post-"finished" releases will likely be even worse.
What I think: Being finished is not a property of the software. It's a function of skill of the maker to spot true opportunities to improve things, the skill of the maker to understand their own limitations to implement stuff (time, money, skill), and the current state of the software as it relates to the world.
It requires ongoing judgement and taste. If any of the inputs change, as they do, the answer changes.
When things get super trivial, you can probably consider them done at some point, but I hesitate. Let's for example just consider "cd" (the shell function). A typo like "cd /home/user/projcts" could offer a smart correction. If you went to "/home/user/work/clients/acme/backend/api" previously, through better usage of nav history you could maybe just get there by using "api".
Not claiming these off the cuff examples are great, and that they might not survive additional consideration, but it's fairly easy to see that they are arguable (and implementations like these already exist in some tools)
SpeedCrunch is much more complex and very far from inconceivably improvable, in my opinion.