If your stateless password rules are stronger than a backtracking RE engine, I have bad news for you.

Few password rules can’t be expressed in such a regular expression, but there are definitely some where doing is impractical or absurd. To take an example I’m familiar with, on FastMail and Topicbox we use Dropbox’s zxcvbn (a truly excellent library embodying a sound approach to password security), and flat-out deny passwords that are expected to take less than 10⁶ guesses, as too weak. I shudder to think how many megabytes long a regular expression to validate that would be, and how atrociously it would perform.

(Other rules may embed restrictions on use of names, dates, &c. associated with the account. Those may be painful to shoehorn into a regular expression, but doing so is probably generally not too impractical.)

Fortunately, the likes of zxcvbn are very password-generator-friendly, as they’re encouraging the sorts of strong passwords password generators like to make; so long as they also have similar accidentally-weak-generated-password protection, zxcvbn is unlikely to cause any trouble and can probably be ignored in defining a pattern for the generator to use. So long as the form uses setCustomValidity to do its complaining when pattern isn’t enough, and the browser’s password generator knows to look at that and try again, you’re good to go. (This is all hypothetical—I don’t believe any tools actually look at password field validation to see if they did the right thing.)

Isn't best practice to:

1) have a minimal password length 2) check all passwords against a set of known bad passwords

I don't see a decent way to do 2) based on a backtracking RE engine.

It’s a terrible approach, but it is easily feasible. Here’s a simplified pattern that forbids “password”, “123”, “1234”, “12345” and “123456”:

  (?!password$)(?!123(?:4(?:56?)?)?$).*