The biggest consideration here is clarity. By requiring opt-in to animate, developers would know exactly which layout has the animation enabled and hence would have an easier time debugging if something didn't animate as expected. In contrast, if layouts all animate by default, it'd difficult to narrow down the cause if the animation didn't behave correctly. In addition, customizing animation is more straightforward when you opt-in to animation, since it's on the same code path as where the animation is created.
Another consideration is performance. Even though
animateContentSize
is animating at the measure/layout phase, it is possible that the per-frame size change can invalidate subcompositions elsewhere in the tree, which may have performance implications. When you define animations explicitly, it is much easier to notice such performance impact and restructure your layout as needed.