1. The attacker either captures the OTPs on the real website, or on a phishing page. They do not have access to either the website's store of 2FA tokens, nor your password vault.

and

2a. Having you enter one or two OTPs on the login page is not enough. The phishing page can claim "wrong OTP, you can try again in 30 seconds" to get at least two codes. The attacker can open a login session and go to down immediately when you enter it, but if there is a protocol where there's a delay of e.g. 24 hours, they would need to phish you again after 24 hours and that's unusual for them to bother with (beyond opportunistically) as far as I know

or

2b. The attack isn't automated and the attacker is also not laying in wait for someone to fall for the phishing (like when having sent 10 phishing emails and waiting for one employee to bite such that they can get into an organisation). In that case, the OTP almost certainly has expired and can't be used anymore

While #1 is common, #2 is rare as far as I'm aware. Once you're into an account, you usually can navigate to e.g. a transaction page within a few seconds and then enter the same OTP¹ again (because the time window hasn't expired yet) or ask the user for a new one a few seconds later as described

A great protection against this would be a device that displays what it is that you're authorising, such as these old bank card readers that show on a little screen like "login" or "transaction of 1337€ to NL00RABO0123456789", but these go well beyond the standard 2FA seeds that you can store in a vault

Either way, you're right, there is this benefit of having 2FA even if you store them together. If this is within one's threat model, but theft of your vault is not as big a concern, it's a valid solution

¹Yes, OTP can never be the "same" by definition. But this works in 9 out of 10 customer sites that we see (security consultancy firm; thoughts are my own yada yada)

Most sites require 2FA for changing the password, but do not require the password for changing itself.