As a side question; what other purposes do you have with the world matrices, other then rendering?
In many of the sports games that I've worked on, the gameplay code and the animation code are quite intertwined. e.g. The character controller, the AI and the game rules themselves will make decisions based on the location of a player's hand bone.
In many games, animation is entirely in the realm of the renderer, and the animation results aren't required to be known by the gameplay at all... but in these games, that's not the case at all!
Likewise in a game like Counter-Strike, the server has to run the exact same animation code as every client, and then use the computed bone matrices to place the "hit boxes" in the appropriate locations so that the gameplay can tell whether a shot was a hit or a miss. Counter strike servers actually keep a history of this data and support rewinding player skeletons to poses in the recent past, so that bullet paths can be tested at the exact same moment that a client pressed their "shoot" button rather than the moment in time that the "shoot" packet reached the server (lag compensation). So even on a no-graphics dedicated game server, there's multiple redundant copies of "renderer" data floating about!
I don't like the idea of updating/ creating matrices outside the update/ within the rendering, because I then I would have redundant operations on matrices. I.e. updating the one based on the new state, within update, for everything but rendering, plus having to create one for rendering only, with the lerped position, rotation etc.
The renderer's matrices are fundamentally a completely different bit of data to the "update"'s matrices. You can't get around the fact that you'll have "redundant" matrices -- that's a core feature of the system.
Also, if you use something like Bullet/PhysX/etc for physics, then objects will have a matrix within that bit of middleware, completely separate from your engine. If you draw an object, you have to place its matrix into a constant-buffer/uniform on the GPU, which again is completely separate from your engine. You can't get away from the fact that this data gets duplicated at different points. If you take a hint from functional programming languages in regards to immutable objects instead of OO's typical mutable objects, this can actually result in cleaner designs! Moving parts are the cause of breakdowns, mutation causes bugs :)
