Sure... but you posted additional arguments so if I let them go without comment then they stand on their own. For some reason the "Here are 900 points about why you are wrong and let's stop talking about it now" thing always frustrates me.
The main VrAppState itself could/should be handling this hardware detection and attaching whatever other additional things it needs (or not).
Except if my app already extends a different application base class from some other library that did this.
This is the primary reason why composition should be preferred over inheritance (specialization). In a single inheritance model, "subclassing to gain behavior" automatically rules out a whole bunch of options.
Then JME is broken. That's what we're trying to fix. When BaseApplication is (mostly) a dumb-passthrough for app states then there should be no real reason to extend it (even applications wouldn't have to extend it). You should be able to do everything without extending.
As long as you are forward-thinking about your design and try to encapsulate as much as possible in app states (even if you still have VRApp to set this for the user) then everything is golden.
I have two main reasons for butting my nose in here:
1) because it's a great use-case to make sure we are doing the right flexibility changes to the engine to support your various use-cases.
2) because a bit of discussion might save tons of refactoring later when we go to incorporate this "officially". Your prime concern is producing games. Our prime concern is producing a long-term useable and supportable engine.