Since modified and created aren’t shown in the field-editing interface, I don’t see that my proposal/proof-of-concept really does anything to facilitate “messing with” them in any way (though I do think access to modifier and creator — as links to templated field overviews — will be especially useful in multi-user wikis!). My design also doesn’t make any automatic links to type or tags or text, since those also aren’t straightforwardly present in the usual edit-field array.
I should mention: I do in fact often find myself manually specifying a value for modified, using the “add new field” workaround. The “recent” sidebar list is useful for some audiences such as students who need to see what’s been added or changed. So I try to turn timestamps off before doing a cosmetic or technical fix. (Perhaps I’m refactoring some old “stupid” one-off style declarations, to move toward a cleaner css-class approach, but I don’t want students to think there’s really something new to see under “midterm assignment”)…
All that works fine if I’m really paying attention. But maybe I forget to turn timestamps back on before returning to substantive edits 
(so now I need to “touch” a bunch of tiddlers that I’ve updated during the lapse). Maybe I even tweak creator and created, if I actually made new tiddlers while timestamps were off). Or, I simply forgot to turn timestamps off before certain minor edits, and now want to back-date those tiddlers (to push them away from the top of the recent tiddlers list).
At any rate, your point is well-taken that some fields are more-or-less “off limits” for end-user use, and some kind of warning or extra step makes sense before allowing edits to them (even independently of my current experiment in design).