Yes the batched tick system (tick.AllowBatchedTicks) was designed to deal with similar issues as is discussed in that talk, but it was designed to be simpler to enable and not require any type-specific setup. In some cases it is just as fast as the manual aggregation approach, but manual aggregation can have better cache coherency. It’s hard to predict which method will be better for a specific game as it depends on your exact setup.
For the cases we were looking at inside Epic, it made more sense to update objects of specific types using Mass which has the best cache coherency but requires more work to set up. But, we still had many other types of objects that needed to tick (many of them blueprints) so type-based sorting didn’t help at all. Turning on the batched ticking still helped with cache coherency because it will often tick components of the same actor right next to each other (if they are registered at the same time), and the task overhead is significantly reduced.
Batched ticking in 5.5 should be good to use for simple actor/component ticks, but it does have a few subtle issues that were fixed in 5.6. 5.6 has a lot of other ticking/update improvements that we did to get the Witcher 4 tech demo running at 60fps. Some of the tech talks on the full schedule (specifically The Road to 60 fps) talk about the improvements.
TLDR is that the correct approach totally depends on your game, but batched ticking is easy to turn on and experiment with before trying other approaches.