OP here.

I tested much higher rates for short bursts, and wasn't ever rate limited, but didn't want to risk blowing anything up. However, with a few AWS instances / lambdas it would have been possible to do it in a few mins.

Secondly, and more importantly, I found a variant (mentioned in the article) that allowed me to do this before meetings started, so you could have the password in advance.

On a single machine with 100 threads. But imagine what NSA (or any other relevant intelligence agency) can do for listening into some foreign government's meetings like the UK one in example. Or what huge corporates can do for corporate espionage.

Don't forget that many recurring meetings reuse the same password.

If you can choose the password, people will also use passwords they use for other things.

I agree, but the point I'm trying to make is that the time to guess the password isn't too big of an issue for passwords that never change. Ideally, Zoom would generate a password for each instance of a meeting.

Failing that, having some better factor for authentication (known email or number for a given company's Zoom setup) would make it harder to get in simply by guessing a short password.

That's on just one computer. Depending on how many servers (read: how much in AWS credits) you have access to, you could parallelise it nearly infinitely.

You missed the part where he said that you could just throw more servers at the bruteforce and drastically cut the time required.

This attack horizontally scales really well, and you don't have to try all 1 million passwords in the average case

It won't necessarily take that long though. That is an upper limit.

I would imagine using a GPU compute instance would bring this time down significantly.

It's network bound, not compute bound. A GPU wouldn't really help in this case.