On ABZÛ we ripped out multiplayer and lots of other cruft from AActor and UPrimitiveComponent - dropping builtin overlap events, which are a kind of anti pattern anyway, not only saved RAM but cut a lot of ghost reads/writes.

This was true even in the first version over 20 years ago. In a single player derivative, I remember combing through tons of UScript, unrealscript, stanzas which went something like. "Do this, and if we're in multiplayer, do this too or instead." The code was a messs, but again, good times.

Really interesting analysis of where the data lives… cutting 3-4 textures would save you more memory even in the 100k actor case, though.

This is a really good writeup. Something the author doesn't mention is that shrinking your data structures is also helpful for cache cohesion: if your structures are smaller, more of them can fit in smaller CPU caches (even if the game engine is striping resources of the same kind to simplify ripping across them every frame, this can matter).

The only counterweight I'd add is that if you later decide to add multiplayer, that is very, very hard if the engine wasn't set up for it from the beginning. Multiplayer adds complexity that exceeds simple things like getting on the network and sending messages; synchronization and prediction are meaningful for a realtime experience and are much easier to get to if you've started from "It's multiplayer under the hood but the server is local" than "We have a single-player realtime game and we're making it multiplayer." But that's not a reason never to do this; not all games need to be multiplayer!

You would probably want to avoid having tens of thousands or a hundred thousand actors though, they're pretty heavy regardless. There might be a few reasons why you'd want to have that many but I think ideally you'd want to instance them or have some kind of actor that handles UObjects instead