I’m not clear on your use case so just sharing some dev/testing and past experiences, if
a) you have 1 common skeleton and many separate meshes sharing the same skeleton/anims and each mesh is controlled by 1 client, ie, mmo setting, as long as your mesh is low poly with low bone count, it is technologically possible to have up to 50 on screen at 1 time in a low poly scene. This is warcraft/minecraft mmo tech, which is about 10+yrs old. The bottleneck here is syncing up N clients reliably which html5 alr caters to as far as 2d games are concerned. In wc mmo, the raid limit is typically less than 50 characters and they also impose zone limits to reduce instance server loads. So per client load is always limited to ensure realtime playability. This is something you have to do on your own end. Imho, based on past bjs low poly mmo demos submitted by other users, it should be possible to get <10 bjs clients synced and interacting. Feel free to browse our Demo and Projects section. As 5G standards evolve and systems getting buffer, I fully expect this ceiling to lift up.
b) you only need many npcs (think starcraft swarms) that animate separately and share the same base mesh but with different textures, you can consider using VATs (Vertex Animation Textures). We have an entire thread on it and bjs has proven itself here as it is possible to offload processes to gpu. Bottleneck here is how buff the client side system is and that is where you need to target client-side system.
c) last but not least, you can consider particle systems. We have excellent documentation on it. Feel free to refer to those.
Ultimately, good perf is a result of how you cast your limits and structure your scene so client-side gets best experience. Hope it helps.