In this example, they waited three days before trying to utilize the broken account; with 2fa they would not have that luxury.
And this (asking for 2fa in the phishing page) would entail a risk as well; if they prompted a user who did not have 2fa for their 2fa credentials, then they would immediately be (at best) confused, and possibly suspicious, so they would have to decide to take the risk as to whether to attempt to target 2fa'ed accounts. And if they don't offer a 2fa prompt, then the phishing attempt has fizzled, as even with the password, they only have one factor.
Any sort of re-ordering of the login process by the good guys is only effective if the customer is extremely suspicious of changes in the login process, which nobody will be. The phishing site is under no obligation to match their flow to that of the faked website unless not matching by itself would be suspicious.
If a human has to be involved on the attacker side, then this gets tricky, since they only have a short window where the 2fa is valid. If an automated process is trying to log on, then it is possible that CAPTCHAs would either prevent getting a full interactive session (i.e. just a "read email" level of access, as for an app) or block the attack entirely.
If 2FA was supposed to protect your password from being phished, then it would have to prompt you for your 2FA code every time you log in, which would be pretty annoying.
What if the password input would only be shown after the user typed in their username, pressed submit and confirmed that they were trying to log in using their mobile device?
* Input username
* Press submit
* Interact with mobile device for 2FA
* Input password
* Press submit