The more work you have to do to change anything in the UI, the more improvements you end up saying "no" to. Great UIs typically get that way via an enormous number of tweaks and improvements (both small and large) at every stage of the design and implementation process.
Early prototyping, designers and developers working together directly, continuous builds, frequent feedback from users—all of these things feed into this improvement process and make the end result better. I'd worry that formal specifications would have the opposite effect.
I understand what you are saying but I don't agree. As I wrote in a parent comment, should you want to change one thing, adjust the specification with the developers, agree with the stakeholders, implement. Done. This is just a spec to follow and reference.
Since you say “commercial” software I’m confused. Would that exclude medical software, aerospace software?
If what you are getting at is that it is not widely used/not used in anything “successful” and thus just a pipe dream, then I understand your concern. But that doesn’t mean it can’t be a useful strategy for some fields nor that it couldn’t produce more reliable systems.
Early prototyping, designers and developers working together directly, continuous builds, frequent feedback from users—all of these things feed into this improvement process and make the end result better. I'd worry that formal specifications would have the opposite effect.