There are two different performance problems Funcom is trying to solve with this change. One is the lag and the other is the server framerate and they are not the same thing.
Lag happens on the client and it’s caused by two different things. One is rendering and animation, another is network I/O. Having too many followers in one area is going to cause both, as your hardware struggles to render and animate all of them and as your network connection has to deal with continuous updates from the server for a large quantity of actors.
Server framerate is basically how fast the server can handle all that it has to simulate. The higher the server framerate, the smoother the game runs for everyone. It is not directly affected by the appearance of what it’s simulating, just the logic. Depending on how much of the simulation is server-authoritative, this might or might not include skeletal animations for NPCs and followers.
This is why it’s currently such a big problem when someone crams 400+ thralls in a single base. From the client’s point of view, it’s a nightmare, because you suddenly have 400+ actors to render and animate, and for which you have to keep receiving a ton of update traffic from the server. From the server’s point of view, it’s a different sort of nightmare. If you have 400+ actors in a single base without any players in the rendering distance, the server won’t bother simulating them at all. As soon as even one player enters the rendering distance, the server has to start simulating all of them – and there’s possibly a catch-up logic to execute which makes things even worse – which can cause the server framerate to drop sharply and adversely impact everyone on the server, not just the player in that area.
Depending on the exact implementation details of the game as it is now, your proposal has the potential to drastically reduce the server framerate problems, but it won’t do much for lag. See, if they do what you’re suggesting, the passive thralls become the same thing as placeables, which are not treated the same way as the building pieces (foundations, walls, etc). Building pieces are completely static: they get loaded in, rendered and there’s not much work to do with them after that. Maybe some LOD adjustments, but that’s it. Placeables are a whole different beast: you have to render the animations for anything that has them (wheel of pain, crafting stations, torches, banners, etc), you have to apply lighting and shadows, etc.
It is already possible to make things super laggy by having a boatload of torches, for example. Passive thralls would have the same effect, so lag would still be a massive problem.
Off topic, I think the best solution would be to limit the follower density. Let’s say you’re trying to place a thrall. The game counts all the followers within a fixed radius (for example) from that spot. If the number of followers is already at density cap, the game tells you “too many thralls in this area”, similar to the existing “too close to another thrall” message, but with different intent.
Having a cap on thrall density would definitely solve lag problems. The question is what impact it would have on server framerate. I don’t know the implementation details of Conan Exiles and the gamedev experience I have is with a completely different engine, but my theory is that it would improve the server framerate and, even more importantly, eliminate server load spikes and help the server framerate degrade gracefully.