And the very fact of the Function keys' configurability meant that they couldn't be relied upon to always do some specific thing, which kind of let devs off the hook. If nobody's going to try pressing F1 anyway, you may as well not bother to make it do anything. Vicious cycle. (See also, and even worse: the "What is This?" window caption-button in Windows, that invoked a modal "Context Help" mode. It was so non-discoverable — and optional! — that I don't know of a single third-party that ever bothered enabling their software to use it.)
On the other hand, if there's a key on the user's keyboard explicitly labelled "Help", then as a developer you'll feel somewhat obligated to put some informative documentation into your app that appears when "Help" is pressed. "Burning" a help function into the hardware, takes away the developer's choice in whether they want to offer help or not, without needing to impose any sort of centralized QA process. The QA process is something the dev will be incentivized to do on their own, when faced with the realization of the inevitability of users' frustrated expectations when they think pressing "Help" will get them some help. :)
This is true, but there is another issue: people who are not techies are not held up to the standard they should be when using computers. If you work with certain software, it is your job to learn to use it well. And if you screw things up because you didn't take the bother to learn how to do it properly, then it is not "the system's fault".
You have to be proficient at least with the system you are using, but people want to use software that is intuitive, even when the task is complex.
>This sort of response is why people dislike techies.
Enter was called "return"..and you know why? Typewriters...carriage return, if you have already functions why no use it? You want a Copy/Paste button too?