They may indeed, never come across the opposite.
I always document the expected input/output type/access mode on the hover-over parameter documentation through the (brilliant) docstring system. Which helps to both inform the user and means that one can read/understand the parameters by simply reading the source code (i.e. not having to hover over them). Less mouse/hovering/waiting annoyance, more fast/snappy keyboard funz (plus it’s great for versioning/documentation straight to .py files).
I realise that this is hardly a “standard” development methodology, but it is one that has been working very nicely for us over the past couple of years (where I increasingly use GH pretty much as an awesome GUI/DAG for accessing RhinoCommon through GHPython, yielding a fast, highly dynamic and interactive workflow). So perhaps we need to differentiate between generic compiled GH components (to which I absolutely agree that one should follow the standard behaviour(s)) and these more context/project specific scripting components written on the fly and not used by a generic “user”, in order to have a meaningful discussion about this (same for the rhinoscriptsyntax vs rhinocommon debate). It’s really rather apples to oranges in terms of usecases.
Which is why I (as the user knowing what I want) simply want the option to set my personal user default, so that I can skip all the mousey/hovery/clicky-clicky stuff.
And apologies for being annoying about this again, owe you a beer next time IRL 
Edit:
That’s a decent workaround (didn’t even consider this!), but still new ZUI inputs will default to ghdoc object no?