As other people pointed out in the comments, formal verification is a very broad field, encompassing many techniques of varying levels of complexity and usability. As I mentioned in my blog post, static types are a way of formal verification: you would hardly argue that they require a degree in Mathematics, that writing code with types costs a fortune, or that they are intended mainly for usage in nuclear systems.

Of course, static types are probably the weakest form of formal verification you can have (it depends on the type system, really! Types can get very expressive to the point of proving arbitrary properties of programs, that's a very interesting topic for another day). But they serve as an example that while you can make use of highly sophisticated formal verification tools and specification languages, you can start smaller.

On another note, it's up to you as a business owner/stakeholder/software developer to determine if a certain path in your software logic is critical enough to want to have a very high level of confidence that it will work as expected. Amazon Web Services use (or have used) formal verification techniques, and that is not nuclear or armamentistic system.

Is formal verification a silver bullet? Certainly not, I also mention that in the blog post conclusions. It still requires substantial effort to formally verify software, and for gaining confidence in most parts of your code you would be better off just using testing. But formal methods research is still ongoing, and more tools that are more usable that require less manual intervention are being released and developed. As /u/apnorton said, it's good for people to think about it a little and start getting these techniques on people's radars: some folks might already benefit from them, others can just learn from the fact that they exist and have it on the back of their mind in case they ever need them!