Basically, what's the new usage pattern to replace Direct3D 11's
set constant buffer for thing 1
draw thing 1
set constant buffer for thing 2
draw thing 2
...
set constant buffer for thing n
draw thing n
D3D11 can use the other pattern fine and is generally faster there too, just saying (though there are a few annoying issues because you can't bind by offset nor map with no_overwrite, and constant buffers couldn't be bigger than 64kb, but you can workaround those issues).
Is this practical for scenes with large amounts of objects?
Yes.
Each person needs at least a world matrix (let's say it's pre-multiplied with view and projection, so a 4x4 matrix) and a set of skinning data (say an upper limit of 96 bones packed into 4x3 matrices).
Best case scenario you need 96 4x3 matrices since you can concatenate the world matrix to the bone matrices before sending them; while sending the viewProj matrix in another constant buffer. Note that if a character needs 40 matrices, you write those 40 and skip 56. It doesn't help the GPU's cache, but it does help with bandwidth.
But still, yes, you're left with 4.608 bytes per object, which at 64kb per constant buffer limit, you can only pack 14 objects per constant buffer.
In such case, just use a texture buffer instead of a constant buffer which doesn't have the 64kb limit.
There aren't many differences anyway in modern hardware, and in older hardware skinning would still be the preferred choice for storing skinning matrices anyway.
It just seems like a whole lot of storage
Yes. But you're thinking about skinned crowd rendering which is one of the things games FAKE. A LOT OF FAKE.
Use high quality normal mapped impostors, upload a couple animation matrices and shared them randomly with characters so they don't notice you're actually playing 32-64 different animations and repeating them. Use stick figures very far away. Play a video about crowds on the background. Use sound to fool people there's more people there actually is. Be creative.
Most objects rendered in a game don't involve skinning, except crowds. Which is where we fake.
especially once you go further down the pipeline and realize you need some of this data again in shadow map passes per casting light.
Whoa wait a second. Yes, you can do that. And it works well for non-skinned objects. But if you've uploaded the matrices in world space in one buffer, and the view/proj matrices in another buffer (and concatenate in the vertex shader); you don't need to reupload the data from the first buffer! You just need to reupload the data for the second buffer (which is 64-128 bytes per pass depending on whether you send the view and viewProj matrices, or just the viewProj)
Finally: What do you think was happening before? You were doing exactly the same, but with more calls to map/unmap and XSSetConstantBuffers. And whatever extra you have to do now, was being done behind the scenes. Now you just get to see the cost for yourself.