I assume in your example you're talking about Get Transform Distance from the ecosystem? Actions like that are trying to cover common use cases while hiding the details, but you can generally do the same thing with a few lower-level actions.
E.g., in your example, you can probably use Inverse Transform Point (to transform from global space to a GameObject's local space), Vector3 Subtract (to get vector to the hit point), and GetVector3XYZ (to get the y component).
As we identify common use cases we try to add higher-level actions that combine a few actions into a single action. Or we can add parameter "overloads" to an existing action e.g. allowing the action to use a GameObject and/or a Vector3 (quite a lot of actions working with position do this).
It sounds like this might be a case where it's worth us adding a Position parameter, or maybe designing a new action that is more flexible...
There are some systemic ways that we make actions more flexible. For example, you can convert between variable types in variable selection popups. But there's no conversion from Vector3 to GameObject. That's essentially what krmko's workaround does.
Another approach: In 1.9.1 Templates can have input and output variables, so you could essentially make your own action from lower-level actions, save them in a template, and re-use that wherever you need it.
Hope this helps some. It is an ongoing battle to balance ease-of-use and flexibility; high-level actions and low-level actions. But your feedback helps us identify areas to focus on!