For systems where 2FA/MFA is "optional" such as Gmail or Outlook.com, the service has to balance the hassle factor of using the 2-factor method and the security it brings to their site. In a perfect world, users would have unique, complex passwords for every site, and always use 2FA when available, but in the real world, you're right - users will have the same password on a dozen sites, and a 2-factor mechanism that doesn't automatically lock the account and notify the user after a few invalid login attempts in a relatively small window could lead to a situation where the attacker patiently tries a few likely guesses until they get to the 2FA prompt, at which point they know they've got a valid username+password combination. With all the highly-public password database compromises on large sites (such as LinkedIn, among many others) that use your email address as your login, then an attacker can logically guess a user's password relatively easily if the user never bothered to update other sites, but just the one that was "cracked".
For security-critical apps (such as one of several I work on), the login prompt requires username, password, and 2-factor value all at once, and it's an "all or nothing" authentication, and we don't tell you WHY your login failed, unless it's because your password has expired (which assumes you entered the correct password, but it's just going to require you to change it and enter that again with another 2FA value to actually gain access to the application). That application has a "captive" user base and the 2FA is required by policy, so it's not directly comparable to the "2FA-optional" sites you mentioned in the OP.
Fundamentally, though, I agree with the comments above that a "token-on-demand" is safer than an "offline" token (like RSA or Google Authenticator) if you're going to do the 2-step authentication because the user will know right away that someone's trying to access their account by virtue of the unexpected SMS messages, either "wrong password" or a valid 2-factor string in the event the attacker gets it right. If the site ONLY sends the SMS 2-factor value on successful login, then it's useless for the very point you mention, at letting the user know BEFORE the attacker actually gets the correct password. The user would only get the valid 2-factor string when the attacker had the right password. By that time, it's probably too late, and the attacker is already off trying that same username+password combinations on other sites that don't have 2FA and the user would have to be at a computer and scramble to change every password on every site they use it on, which if they're reusing the same password everywhere, is pretty much impossible because they won't remember them all.
Ultimately, it's up to the individual implementation as far as how damaging a 2FA can be to other sites used by the same user. Best case, it's an all-in-one login like I described, where the attacker would have to also somehow have their 2FA device or "magic string" (initialization token for something like Google Authenticator), and if they've got that too, the user's already been well-compromised.