There are also VLF-ONE specific issues with having just a few large and complex 5250 application sessions.
VLF-ONE applications give each business object its own 'pane' of command handler tabs. In a large and complex application session, if a business object's pane contains RAMP screens in the command handlers, it is likely to have to load up and initialize a large amount of 5250 application session information it will never need to use.
Additionally, working out navigation paths at execution time is more complex and therefore slower than it needs to be.
In the worst case, using just a few very large and complex 5250 application sessions in a VLF-ONE application may cause it to waste unacceptably large amounts of computer time and resources.
To emphasize this type of issue, imagine a VLF-ONE application that deals with many RAMPed business objects, prominent amongst them Orders, Customers and Products, visualized like this:
Worst-Case Scenario
Here the application designer has used a single large and complex 5250 application session for the whole VLF-ONE application. When Orders, Customers and Products are all open the result can be visualized like this:
Note how each business object is forced to load and initialize an instance of the single large and complex 5250 application session, even though each only requires, and can ever use, the parts highlighted in orange.
Best-Case Compromise Scenario
A commonly used and far better way to do this is to create multiple smaller and simpler 5250 application sessions that just define the RAMP details of a few business objects.
Here a single 5250 application session defines the RAMP details for Orders, Customers and Products only: 
The single small sessions still load and initialize material they do not require, but the amount of it has been reduced to a level that is acceptable in resource expenditure terms.
The 5250 application session reusable session option often works well in combination with this approach.
The shipped RAMP demonstration material uses this best-case compromise approach.
Best-Case Scenario
Here multiple small 5250 application sessions (A, B and C) are used.
Each 5250 application contains just the logic required to deal with a single business object: 
This is the best possible solution because what is loaded and initialized in each session is minimized and all the logic is used.