The pseudo-code example says it all... Normally, we implement a "camera" object with the properties "Up", "Target" and "Position" for creating a view matrix. But what if we toss that notion out and go with something more akin to any other 3D game entity, which has a "Position" and "Orientation" rather than calculating everything in terms of what direction is up and where the target is...?

What problems might this pose in game design? What advantages might it have? I was just curious about this idea so figured I'd ask...

Regards,

--ATC--

EDIT:

Also, what is the easiest way to decompose a projection matrix to retrieve the fov, aspect ratio and near/far clipping planes?

To construct a view matrix you'll always require those three vectors, but you could very well construct them each frame by transforming the local unit axes for the camera by the orientation quaternion. There's no real gain in the method you proposed except for the fact that you use a little less memory in only storing a 3-vector and a quaternion instead of 3 3-vectors.

If I remember correctly a left-handed perspective projection matrix is laid out like this (don't shoot me if I get something wrong here):

I am usually constructing my cameras the second way - although instead of position + quaternion I use full matrix.

The motivation behind it is that now camera is completely "normal" 3D object (scenenode or whatever) and you can use all your standard object transformation and query methods on it. It has bounding box too - it is just the bbox of projection frustum.
Specific camera controllers are built on top of this basic camera and are modifying directly the camera matrix.

Of course in that case you will want to write handful of convenience methods to rotate your camera around target, query position and orientation etc.