Sadly, the post is too short to discuss what "intuitive" means for an API (which could probably fill several volumes).
Behind that button, there was no possible way to make a mistake. Now, to be fair when a constraint was violated ( which only happened when something physically broke or somebody didn't set a physical thing up right ) there was a comprehensive explanation of the failure - "The U42 wire for the Gerfish Space Defarbrulator is disconnected or broken. Please refer to section 1.145.2 of the service manual." That happened in a popup.
To me, that's a good GUI - "just tell me when to go to it." But there is an ostensible public choice theory problem with this approach - who will be paid for training in it? Where will a support network for it exist? Nobody, and nowhere. Show this to people, and you can see it on their face - "there goes my job." They think this even after I show 'em the popup.
It's asocial and that's more important that "it's correct." But it worked to sabotage any expectations people might have about me writing GUIs.
Also, when people tell me that corporations are cost driven these days, I just laugh because of this.
Fixing the API is what you do, for instance, when you write language bindings for the horrible BSD sockets API.
The fact that the user can fix it doesn't mean that API authors shouldn't care about simplicity, easy of use, consistency, etc., but it does mean that they shouldn't overdo it.