If login rate-limiting is implemented properly, then there are no downsides, and it should be used with or without 2FA (and in fact with the 2FA attempts themselves). And account lockout is not the proper way to rate-limit login attempts.
Rate-limiting means you restrict the number of attempts a given source can make. Typically this means a given IP address, though you can define "source" however makes sense in your situation.
There are really three types of attacks you're trying to defend against here:
(a) The attacker knows the password -- in which case lockouts won't help even
(b) The password is easily guessed, like "123456" or "passw0rd", or "zxcvbn". Again, account lockouts won't be helpful because these attackers don't try more than 5 or 10 passwords at the most before moving to the next account. Often they'll try only one. You need to block the attacker, not the account.
(c) The attacker is making a determined go at a single high-value account and will try the whole dictionary and then some. The password may not be easy to guess, but the attacker has all month.
There's not much we can do about condition (a) above, though 2FA can help. Condition (b) is extremely common while (c) is a bit more rare because the success rate is so low. But importantly, both can be thwarted by slowing down the attacker.
I've explained this technique here several times, so I won't go too deep into the details. But the important thing is that it is simple to build, doesn't noticeably inconvenience legitimate users, but it does work very well against determined attackers. By slowing them down, you're effectively setting a hard limit on how many attempts they can make in any given timespan, but doling out that limit incrementally between attempts. And better still, you can detect which users continue to send attempts during the waiting period, which flags them as using specialized software to circumvent your client-side rate-limiting. Cool!
If you set things up like this, then there's no reason to disable rate-limiting. It has no real drawbacks, is largely invisible to users, and offers a reasonable front-line of defense against brute-force attackers.
This only leaves the scenario of a distributed attack against a single login from a large botnet. This is rare enough to never actually happen for most sites, but it's simple enough to detect and address, so I'll leave that as an exercise to the reader.