There would still be the point of requiring knowledge of an arcane syntax that can take months to understand and years to master. It will almost always be more efficient and productive to specify programs in plain English then add additional specifications to clarify ambiguity when observed, rather than trying to write specs in a completely unambiguous language.

    then add additional specifications to clarify ambiguity when observed

That's such a clean, almost clinical way to describe, "After the software has caused several billion dollars in trading losses, bankrupting the entire company." (https://en.wikipedia.org/wiki/Knight_Capital_Group#2012_stoc...)

Imagine if software with large inherent risk was developed using formal methods, and the massive remainder of software was developed using rapid development methods. It's almost like there are different tools, and they can be applied to different jobs to cause improved outcomes based on the overlap between the tool's properties and the job's properties. What a radical concept!

    Imagine if software with large inherent risk was developed using formal
    methods, and the massive remainder of software was developed using rapid
    development methods.

Imagine if we could tell the difference between use-cases with large inherent risk and the massive remainder of use-cases and avoid using software designed for low-risk situations in high-risk applications.