What benefit is there to the enter username then enter password pattern?

There's generally two big reasons I've seen for this pattern:

1. "Single Sign-On"/Multi-Provider support where the email is used as a lookup key for which Provider to use to log in (redirecting to corporate SAML providers or things like that). (Mentioned by most of the other commenters here.)

2. Another "Wish It Were Multi-Factor" process that (mostly American) Banks cooked up to meet regulatory wording at available loopholes rather than address regulatory intent/spirit (real Two-Factor/Multi-Factor support), in this case specifically for phishing protection. That (dumb) idea was that the user in application settings would pick a recognizable "callback" such as a photo of a cute animal and a word they'd notice. Upon entering the username and before entering the password the application would display this "callback" and in theory the user would remember and know better than to enter their password if they saw the wrong "callback" photo/word. In practice I think we all realize that humans do things like username/password login generally by rote muscle memory, aren't likely to stop and "check the cute animal photo" first, and that whatever APIs returned the "callbacks" would be easily scrapable for phishing anyway if the only real input to them was email address (and maybe a rate limit). At least in my experience most of the sites that did this "cute animal wish it were phishing protection" have since dropped the "cute animal" callbacks (because they were silly), but kept the separate username then password flows. It's easy to assume that that's just laziness on their part after they did all that work to separate the flow that they would not be quick to merge it back together.

This is a pretty common pattern for applications that support using multiple identity providers via protocols like OAuth or SAML.

The site looks up the supplied email and decides where to send the user - if they have a password, ask them for it; otherwise send them to their identity provider to authenticate and sign them in at the end of that process.

This does leak a little bit of information about users - a third-party could observe whether "bob@megacorp.co" gets redirected to Megacorp's SAML server or gets a password prompt.

It's not a UI pattern as such but the way authentication can be done when the site in question does not know or manage the user's login credentials. It also serves the purpose of "single sign on" in enterprise environments. In other words, the site you're logging into may not have your authentication credentials for that account and would first need to know who you are in order to decide how to challenge you for your credentials or even who should challenge you for your credentials and authenticate you.

Note that I have used the words "authentication" and "credentials" and purposefully omitted "passwords". That's because passwords are just one way of authenticating users. You could also authenticate users by sending a code by email or SMS or using a client certificate, among other ways.

An example: your company subscribes to Office365 but wants to manage your credentials to provide you a single sign on experience across systems. When you visit outlook.office.com to check your email, Microsoft has no idea who you are or that you need to be authenticated by your company. So it asks you to enter your email address, and on getting that, it knows (based on prior configuration) that your company's domain requires you to be sent to a specific page managed by your company for authentication (of course, your company may have outsourced that function to another provider, in which case you get redirected there). In this setup, Microsoft does not know or care how you get authenticated. It just needs a secure and valid authentication token back from the system that's going to authenticate you.

Depending on the systems and providers in question, the most common underlying technologies would either be OAuth or SAML.

Here are a couple just based on my limited anecdotal observations. Some sites will redirect a user to the region/cluster their account resides externally rather than internally. There may be a mix of technical and/or regulatory requirements around this pattern. And to your point, some sites will retroactively snap in other authentication methods, redirecting to a different endpoint rather than retrofitting the logic internally on the destination servers. Sometimes this is a result of technical dept or prioritization of projects or spending. Sometimes this is a result of adding a turn-key solution that did not easily integrate with existing applications. I'm sure others here can add more reasons than I have seen.

For SAML, IdP Discovery.