It is a good idea to remove identified gaps such as this and provide a de jure method.
What you say may be best practice and would be worthy of a default behaviour, especially when a tiddlywiki is internet facing, however please consider that Tiddlywikis versatility allows for many applications, I for one have a set of them running on my local machine, that only I can access and I use for desktop interaction and to take full control of my browser and desktop. In this case I am not keen to have restrictions imposed, restrictions that may be necessary for the "filthy internet", impact the local functionality/versatility.
Other applications of tiddlywiki can take place in a secure LAN from local servers, apart from the fact such devices may already be hack-able on many levels, this can be a semi or wholly trusted environment. An example may be once a user logs in and has access to tiddlywiki, such as on a Raspberry Pi they may be keen to interact with the device hardware.
The javascript uri function is used with bookmarks as well, and I make use of only a few so far, but they are a big productivity gain.
I believe decisions already taken for robustness in the face of the internet have impacted the versatility off line, this includes lost opportunities for example I would like to freely save files locally without direct user involvement for automation.