You are assuming an internal logic that doesn't really apply here. The message from Jens that started all this was sent in a fit of anger; you can tell because he disallows even discussion of the rule, discussion such as the one we're having now. When Jens returns, either he'll see this thread as honest request for clarification or he'll see it as annoying children trying to lawyer their way around the rule. (I see elements of both, from different people at different points in the conversation. And also a bit of just silliness, which is okay I think.)
The whole getters and setters library is a longstanding point of contention between Jens and me. I believe in Eisenberg's Law, which says that everything you can do in the UI should also be doable in the program, and vice versa. Jens doesn't; he agrees that there is some overlap, but he sees occasional things that can be done by programs that don't have to be doable in the UI (except that you can construct a script to do it, and then click the script to run it, so in that sense everything can be done in the UI), but even more, he believes that there are things you can do in the UI that shouldn't be doable by a program, because UI actions are unambiguously being done by the actual user, whereas program code from a third party might be malicious. That doesn't have to mean deleting files; a while ago there was a big effort by a handful of users to invent a way to make it impossible for users of their game program to read the code of the game, by making it impossible to get out of presentation mode into edit mode. This counts as malicious, given our goal of building a sharing community in which users can freely learn from each others' work. So Jens wants not to have a programmatic way to get into presentation mode, something that I've used in my actual practice, while making tutorial videos.
But for me, it's a principle that anything you can do in the UI should be doable in a program, even if I don't have a use case myself, because the vast user community is collectively way more creative than I am, and you never know what people will need to do in a program. But despite the principle, I allow that there might be a small number of exceptions for really dangerous things, on the order of deleting files.
The current state of the JS Function block is something Jens and I can both live with: users' programs can do anything, but if they use that capability, it first has to be explicitly enabled in the UI. And this is why the getters/setters library still uses JS Function rather than the hidden-primitive feature, so you have to enable it. I wish the error message you get told you more about what the code did, to help you decide whether or not to enable it. Maybe that'll be someone's PhD thesis someday.
, 
, and 
, so that no-one can appear as someone else. The key would have to be stored on the server, and only transmitted to an authorized user. If it was derived from the password, it could be used with hashcat plugins to get the password back. However, it could be encrypted with the password on the server, as long as it could still only be downloaded by authorized users.