Okay, let me explain our use case a little deeper.
Background:
We are a manufacturer of custom engineering lines, so each project has different requirements. These can be a quite large lines of connected physical processes.
In our terminology, a line consists of different modules, each module has one or more stations. At each station there can be one or more physical processes. Each part (the product) is handled through the line and is usually identified by a unique ID.
Physical processes can be screwing, joining, pressing, measuring, welding, laser processes, ...
you name it.
Use case for Node-RED:
We are using Node-RED as a data processor between the field (Siemens PLC, low level) and higher level systems (databases, the customer's MES, etc...).
It is achieved by some custom nodes for the PLC communication and decoding/encoding of raw data structures.
We already try to keep the flows as simple as possible, so complex functions are put into stand-alone services that are just invoked by Node-RED.
Node-RED is merely the "man" in the middle. 
Per station we have to handle different kinds of requests from the PLCs, like the following:
part check-in
- can the part be processed in this station?
- retrieve production parameters (limits for measurements, program parameters
for external devices, ...)
part check-out
- process part-related data (hand over to customer systems, internal
databases, ...)
A common flow looks like this, simplified.
plc in -> decode struct (raw bytes) -> process -> call a service api -> generate response -> encode -> plc out
This is usually a one- or two-"liner" including a catch node for error handling in each flow.
Each flow involves more or less unique data structures, depending on the physical process. These are decoded into an object using a structure definition (Siemens SCL).
Generic stuff is put into subflows and now that these are customizable with parameters (v0.20), they have become really useful!
Regarding the canvas space limitation and tab navigation:
For now the common practice is to put these flows for checkin and checkout requests for each module into a tab. So you would get "M1 - checkin", "M1 - checkout", ... for module 1. Now imagine a production line with 10-15 modules and at least 10-20 different requests per module that need to be handled.
So the number of flows required scales with the complexity of the line (number of modules/stations/processes).
To address your concerns:
The runtime can handle this amount of processing perfectly. 
That is exactly
what NodeJS (and Node-RED) was made for. It is merely a matter of the
presentation in the flow editor and how you can navigate your flows.
From the perspective of software development in the context of custom mechanical engineering, doing all this with Node-RED gives us exactly the flexibility we need. There is often a requirement for "special" handling due to customer wishes. Furthermore, each customer has different backend systems.
Compared to our previous solution, we can apply changes a lot more quickly, now even at runtime. The initial setup of new projects is easier.
And you can actually see what is happening with your data and why, making it easier for colleagues to become acquainted with the project's specifics.
From that experience the last 1-2 years, I believe moving to Node-RED for that
kind of stuff was a perfect choice. 
Quite a lot of text.... I hope I wrote it in an understandable manner. 
