another angle is the business perspective.
a lot of software is deployed in the service of the goals of business. To serve that purpose it often isn't necessary for the software to be completely correct. If it is probably sort of correct that's often good enough. Better to have something sort of correct deployed and running next week than something that costs more money and time to build, is a lot harder to hire people to maintain, relies on a formal analysis that is highly sensitive to changes in assumptions, and achieves a level of correctness that is unnecessary for the situation.
from this perspective, investing effort into formal methods will often give a poor return on investment compared to alternatives of hacking things together & running a few tests to catch obvious defects.
In some situations it seems to be worth investing in formal methods. Eg relatively well defined systems with very high costs if they fail.