Level's of acceptability are determined based on an organizations or individuals risk appetite. 2FA is not a silver bullet, and as a pen-tester I'm going to pop any box I can (whether it be admin, or not) and then work on escalating privileges. 2FA will not protect you against system vulns that can provide access to
root, so if I have a foothold in your network via a compromised workstation I'm going to start fingerprinting services and try to get domain admin. Compromised end-user workstations also provide potential pivot-points into additional networks (perhaps dev environments where things may not be as secure). If you want to make life harder for threat actors, enable 2FA org wide if possible.
There are a lot of these lists available, but check out This GitHub Repo which contains several lists of the most common passwords utilized. A warning: You will be shocked and dismayed at what the most common passwords that are still being used.
Again, your reasonable minimum length is going to depend on what you're trying to secure. Ultimately as security people we'd love to see massively long passwords with high entropy spread across an organization, however that may not be feasible in many instances. Security is important but should minimally impede an organizations ability to be productive. A LUKS decryption key for a very sensitive server's full disk encryption which is only entered when the system boots up is likely to be very long more random. Conversely, your average end-users login to the workstation which is used every time they want to access their workstation is likely to be shorter and much less random. Despite what any best practice says you need to find the sweet spot of secure-random passwords with usability.
EDIT re: Password rotation : The concept of forcing people to change their password is a contentious topic to say the least. On one hand you forcing them to change their password potentially mitigates password replay attacks. On the other hand you get password rotating and minimal changes (password#1, password#2, password#3) etc.
It's important to understand that Pentesting is not a truthful representation of your threat exposure for one simple reason: time. Penetration tests are limited timeframe engagements, whereas an attack with an axe to grind has a much larger window of opportunity. I might spend two weeks with a client, but once an attacker has a foothold in the network there's no telling how long they might poke around undetected. If I'm running a 2 week pen-test and there's no luck with password replay attacks after a few attempts, I'm likely going to move on to other attack vectors. It's easier for me to XSS or Spear Phish someone that waste CPU power on brute forcing or attempting to re-use people's passwords.
Now with that said, I like forcing users to change their passwords even though I inevitably know that passwords will get recycled. If I set a password policy to have users change their password every 60 days, and remember their previous 6 passwords I know that in a year there are 60 days where a stolen set of credentials might work. As a sysadmin I like those odds, as an attacker I don't. If users could be trusted to use a completely different password on each service they use, then ditching the age-old adage of "Change your password every x days" would become feasible, but that's nothing more than a pipe dream.
As there is no way to enforce staff to use unique password on each service (at least reaonsably unqiue (ie not password1 for your email, password2 for your laptop, etc) then I don't think password policies are going anywhere any time soon. Knowing that passwords will likely get reused, the responsibility then is on the organization to implement additional controls (2FA, network segregation, Intrusion Detection, etc) to round out their internal security.