Should we apply matrix optimizations to superthree?

Description:

See background here:
https://github.com/mrdoob/three.js/issues/25115

Based on feedback received here, it looks like neither #25114 or 25142 is going to be accepted into THREE.js due to unavoidable API changes.
https://github.com/mrdoob/three.js/pull/25142#issuecomment-1357345258

Specifically, these changes require that we don't allow sub-classes of Object3D to override updateMatrixWorld(), instead providing a alternative API for sub-classes to extend updateMatrixWorld() processing.

THREE.js maintainers see that as an unacceptable level of API change.

For A-Frame, I think there may be a different balance:

• I think this restriction on the THREE.js API is far less problematic
• Due to the way A-Frame models a-entitys with multiple THREE.Object3Ds, the potential performance gains are more substantial
• As a platform that targets VR, and hence frame rates of 72fps+, A-Frame likely cares more about performance than THREE.js.

Hence might be worth considering taking these changes into superthree.

I'd be happy to do a PR for that if it's wanted.

Thoughts / feedback?

Start by reading the linked background issue #25115 and the discussion in PR #25142, then inspect the superthree integration point mentioned in this issue. Determine whether the proposed matrix optimizations fit A-Frame's Object3D model without the rejected THREE.js API changes. Done means an agreed approach and an accepted implementation plan; no file or test is named here.