This was one of my personal favorites in that release (the removal, that is); the delay cause some confusion for users and developers that had no indication that the activity wasn’t animating during that startup phase.
So why was it there in the first place, you ask (or I’ll pretend you did, anyway)?
Or, more complicated: older devices tended to thrash the GPU too much, causing noticeable jank in both the window animation (as the activity window was settling into place) and the activity animation (animations running within the activity itself). So rather than cause obvious performance artifacts everywhere, we opted to just put one of them on hold (the animations within the activity), thus allowing the window animation to run smoothly.
The reason that this particular operation caused jank was not just that the animations were using the GPU (everything that renders does in Android, at least since the ICS release). Rather, it was that there were two different processes that both required access to the GPU. Typically, animations are running when the system is dedicated to showing the results of one process (the foreground activity). But in this case, the GPU was required to run the foreground activity animations (running in the activity’s process) in parallel with the window animation (running in the system server process). This caused the GPU to have to context-switch between these processes, which can be expensive, especially on older devices with more limited hardware. So it was the right decision at the time, as the result was smoother on screen than the thrashy behavior before that “optimization.”
But fast-forward to 2015 and the common devices (not just the high-end ones) are capable of much more performance, and context-switching doesn’t take the GPU down as much as it did then. Some performance testing results later and we opted to back off to the previous behavior. Now we can run all the things.