9 times out of 10 the answer to my questions have been pointed out in the documentation. However...

Quite often I want drive a parameter with an attribute, good example being painting a point attribute to drive the height on a mountain sop, which you can do by naming the incoming point attribute @height. It isn't mentioned in the docs at all as far as I can see but why this works becomes clear if you dive inside the mountain sop attribvop and find a bind that imports @height, and I can also see all the other things that are bound in which is helpful.

Now I want to drive the wire radius on a polywire sop, again nothing in the docs in mere mortal language, but some forum searching and ah! I can just stick an @myfloatval in the wire radius channel.

Is all this information in the docs in a way I just can't see? Do I just need to rtfm properly?

Yes I can see this on the polywire sheet:

The four numerical parameters support all the local variables of the Point operation, plus the LSYSTEM specific variables of $WIDTH, $SEGS, $DIV, $LAGE, $GEN, and $ARC.

To some degree it's gobbledegook, and I see more than 4 numerical parameters so which 4 does it mean, and my only experience of local variables is in wrangles where I can see how to tie them to incoming point attributes.

I really want to learn but I feel like I'm staggering around in the fog!

The docs could definitely be clearer. When I hover over the "wire radius" param tool tip on poly wire for example it says "This is the radius of the wire to sweep over the polygon". Adding, "It can be driven by a point attribute" would go a long way. However when building networks I don't really have time to dig around in the docs hoping what can/can't be controlled with what kind of attribute is described somewhere. It would be nice if the parameter pane had a way to filter parameters by class type so if you were wondering what could be driven by a point attribute you would just enable the filter and all the other parameters would be hidden or dimmed or whatever.

Per component Local Variables are old concept and only old non compilable nodes may still have them
That's what you will see in the docs under node's Local Variables section
At some point @ syntax was added to bind attributes directly by name for those to remove a need to create local $ variable for attributes

As for HDA with VOPs inside, you just have to investigate
A lot of those may contain Parameter VOPs, which like Bind VOP will bind attributes by the same name or type so it can be completely unintended by author and many of them are even simple parameter names which makes higher chance of being unintentionally overwritten
The only way to identify them and document is if the HDA author was consciously aware of all of them and whether they would be overwritten from attributes from HDA inputs since those attributes would need to find their way to the input of particular Attrib VOP

The new pattern for controlling Parameters with attributes is usually adding the choice in UI to specify Set or Mult a parameter by attribute and also specify attrib name
This however is not consistent and also highly depends on HDA author to build it that way

But I'd say if it's not obvious from UI, not mentioned in help directly or not listed in Local Bars, chances are it is unintentional and for those nodes we may be just lucky it's possible thanks to how VOPs work

One sure thing is if node has VEXpression parm then you have more control and it also suggests that at least some parameters are controllable by attributes, even though VEXpressions also don't have consistent logic inside and some nodes pass exact value from HDA to the vex variable to be processed by VEXpressions while others silently modify the value before passing it which may be very confusing and impossible to modify the intended value

Anyway, with Houdini allowing so many ways to approach this and no clear guidelines or best practices, it's more about experience and knowing what to look than consistent logic or rules that would make it obvious