Easy answer is that it would provide access to base forms that are never instantiated. Some mods (especially those written before OBSE arrays and string vars) create items to store information on and never actually place these items in the game world. Think of them as a ghetto struct. The scripts rely on the base forms being essentially unchangeable by other mods.
Wrye Bash tries to work around this issue by avoiding forms if they match a variety of criteria (one red flag being if it has "Token" in its name or editorID).
I realize that there are ways to get at other mod's objects indirectly e.g. through inventory-walking cmds. Those aren't immune to conflict either, and we're never going to eliminate all potential for conflict between mods. But providing commands to directly access stuff belonging to other mods just seems like it would encourage conflicts.
Of course the data handler's form lists are already exposed to obse plugins so there's no reason commands to access them can't be provided without including them in OBSE proper...
I have the feeling that I should let this lie - and I will. But humor me a closing argument
The problem with a GetForm command, I understand, is that otherwise 'hidden' objects would become visible to scripts. Since this violates an assumption made by many mod authors, it might lead to a new wave of subtle and hard to reproduce incompatibilities. I don't contest this, but I don't understand why it elicits such a strong reaction. Just because the functions
could cause problems doesn't mean that they
will.
Allow me to offer an example from my own experience - the commands to Add/Remove Effect Items. They allow low level access to magic items, and many mods would not be possible without them. But if used unwisely - changing a spell that is currently active on a target somewhere - they cause memory access violations, and often a CTD. This isn't seen in practice only because script authors are generally aware of the problem and work around it. I'm not arguing that script authors always know best - I was one
. But I think that careful design and good practices go a long way to overcoming such pitfalls.
For instance, there can be no harm in a script that looks through the data handler but doesn't change anything - so you could use these functions to gather statistics, or balance your own mods items against what's already in the game. And as Waruddar pointed out, an object's current properties are sometimes enough to indicate whether it is safe to change - so if you were retexturing potions, for example, you might check if they use the vanilla potion texture first. The potential for conflict is still there, but it can be avoided with care.
Simply put, I think that there are enough situations where a script could make intelligent use of the data handler to justify the additional complications. I know I personally would be very grateful for it, and I think others could as well. Having said that, I'll step off the soapbox and move on.