Hi, some interesting questions and there is always room for more helpful information.
You will certainly want to split things - you rapidly reach a level of complexity that is very hard to follow on a single tab. I don't think there is a special right or wrong way though. I tend to keep the first tab for setup and general configuration - global reference data for example.
Here is an example from my new setup that will eventually take over from the old live system:
And here are the tabs from the current live system - this is actually a few too many to work with comfortably since you have to scroll:
Hopefully reasonably logical partitioning.
There are, of course, several ways. However, it isn't always convenient or sensible to rely purly on the exchange of msg objects. Reference data, for example, is often best kept to hand in a variable. The most common use for variables is to retain the last input from MQTT topics for further processing.
In common with any programming, minimising global variables is sensible but over thinking it in this context has no real gain. I make reference data global because if I make it more local, I inevitably end up trying to use it in another tab and then getting annoyed that I didn't think far enough ahead 
Now that we can retain variables as well, they've become even more useful.
However, I also make liberal use of link nodes. These really free you from the visual constraints that flow-based programming general comes with. Lots of crossed wires! I use them in the same tab to simplify the flow visually and, less commonly, between flows if I want to keep some particular process all in one place.
When I know JavaScript well enough and realise that a simple function can replace a snake-nest set of nodes 
When JSONata came into Node-RED, I started to go a bit mad with it until I realised that bending reality to JSONata's way of working isn't always an advantage over straight JavaScript - if you know how to write JavaScript.
The rule of thumb I now use is: Which will be simpler and which will I most likely be able to understand when I come back to it in 6 months time?
Yes(ish) to the first part. I make extensive use of descriptive "names", I tend to use names as a title more than a name. For example:
I don't know, however, that flows would ever be fully self-documenting just with names. I also make good use of comment nodes as you can see - I also use them to help differentiate parts of the logic visually. I really wish for an ability in Node-RED to group nodes together (like "containers" in Visio if you've ever used that).
The latest beta for Node-RED contains the ability to add descriptive text to any node which is fantastic - it integrates to the info sidepanel which works really well.
Adding names to input and output connectors can also help remind you what data you are sending/receiving and I do that more and more as my flows get more complex.
Nope! But flows not only have a maximum canvas size, you will also quickly realise just how painful it can be to follow a flow once it gets larger than a single screen-full. I try to keep all my flows so that they don't overflow horizontally on my normal monitors. I find vertical scrolling much easier than horizontal. Any single piece of logic really needs to fit into a single screenfull however and I'd rather break things up using links than make some logic that can't be read on a single screen.
This really isn't an issue with Node-RED in my opinion. Indeed, I commonly have something like a single MQTT output node with a great many inputs. However, I now generally avoid this by using link nodes.
