We want the money back guarantee because we think the specter of you making no money will motivate you not to fuck us over. Your guarantees mean next to nothing, and the manpower involved in getting and cashing that check might eat most of it up anyway.
In my experience it is. Sure there are people who can go in and hack some simple code, but they typically know nothing about the clean code style that you need to make millions of lines manageable. They do okay with 500 lines programs where it isn't hard to know the whole, but don't put them on anything more complex
If only vendors didn't force users into closed, proprietary IDEs which lack many basic syntactic checks, developing for industrial control system would be much more pleasant.
For reference, I'm currently dealing with a customer whose most complex machine (which automates a job that used to take two people per shift) runs on 128 lines of code.
Coding is really not a limiting factor in manufacturing automation. For decades everything has been built around being controlled by first relay logic and then PLCs, which implement multiple languages like ladder-logic which are basically already drag and drop. Most sensors are simple - generally they provide a boolean on/off signal, and occasionally there's an analogue output which is pretty easy to interpret. Physically placing and wiring the sensors correctly is the hard bit, not interpreting the data. There are more advanced systems, like computer vision, but they all already have user interfaces which allow you to interact with them without coding. In fact it's actually a real pain in the ass that in most cases there is no coding option, and thus everything has its own proprietary and arcane method of operation and its unreasonably difficult to get things to talk to each other.
Further, generally coding skill is not particularly lacking. Assembly-like languages such as G-Code are widely used by machines and many tradesmen know enough to hand edit at least simple programs, and the engineers on staff are generally comfortable with more advanced programming. While they're a far cry from software developers, but it's sufficient for the relatively simple cases that a no-code solution might be suitable for.
The main issue for automation in manufacturing is not versatility but reliability. A few hours of downtime can cost tens of thousands of dollars, and a machine crash might easily cost 8 figures, to say nothing of the potential for injury or even death. Whatever difficulty there is in coding for manufacturing environments is in structuring these programs such that they are consistently accurate and fail safe. Personally, I don't find anything that makes it easier for someone to tell a machine to do something stupid particularly appealing.