That's about the same that would happen when you override "render" and modify "painter.state.projectionMatrix3D". The "camera" properties on the stage are just an abstraction for that matrix so that people don't have to think in terms of a matrix, just as "PerspectiveProjection" is in classic Flash.
However, there are side effects, even though it's not immediately apparent. For example, when you call "DisplayObject.getBounds(target)", I need to calculate the bounds of one object in the coordinate system of another. That must also work for 3D objects, which is not straight-forward, since you need a 2D rectangle as output, not a 3D cube. Thus, I have to project the vertices onto the 2D stage; the result of that operation depends on the camera position, of course. But what if those two objects have different cameras? 😳
It all gets quite complicated quickly, and if you dig a little deeper into the Flash implementation, you'll notice that it produces incorrect results in many situations. I wanted to create a pretty simple 3D game once when the 3D coordinates were introduced in Flash, and I had to add dozens of workarounds because of all the inconsistencies I encountered. In Starling, Sprite3D works quite flawlessly in its current state, even when nested (it's always nesting that lets this stuff become complicated).
I don't say it's not possible to implement that more flexibly — I just have too little experience in 3D math to get this done in a finite time frame. 🙄