OK. I'm sure I'll miss something, but we'll see how much of that I can cover.
Hundreds of users and JSF is not something I have any solid numbers on. You might be better off using Struts
, but I also have no benchmarks for that framework on this sort of thing. JSF is easier to work with than Struts, but I think Struts might make it a little easier to cut down on some overhead. The good news is that JSF is not a jealous framework and apps can be written that employ JSF, Struts, and raw servlets/JSPs all in the same app (as well as other alternatives), all doing what they do best.
As for the "quick-and-dirty" platforms, their problem is that they are exactly that. Quick and Dirty. They don't have the security or even general scalability of J2EE and often once you get past the basic "gee-whiz" instant app stuff and into the ganrly real-world junk, they can be more liability than asset. I mostly use Python for command-line quickies, although Django is nice for what it does. For quick apps, my go-to is PHP. But the heavy industrial stuff is when I switch to Java.
I'm not sure I got your flow requirements right, but JSF - and Struts - are good at "wizard-style" data input workflows. JSF isn't very good for "pop-up window" workflows, but I don't like having browser windows/tabs opening up all over my already-crowded screen anyway. You can get a "pop-up dialog" equivalency from some of the extension tagsets such as RichFaces, but they do tend to be a bit of a pain.
As far as parent/child "forms" are concerned, in JSF the main thing is not the View, it's the Model. When a wizard sequence is being processed, it's common to have a shared backing bean (Model) object maintain the composite data and possible "helper" Models handling the per-View specifics. In practical terms, that means that the Wizard core object is a session-scope object and the individual view models are typically View-scoped (or, when possible, Request-scoped) with the master (core) object injected into them so that they can reference/update the core data as needed.
One of the advantages of the Model/View/Controller architecture is that the same Model can be presented in different Views having different appearances. Even at the same time, if you like. A classic example of that would be where on-screen you have both a graph and a spreadsheet view of some particular model data. That's because when properly designed, Models and Views are completely self-contained and the Controllers are what bind them to each other.