I'm certain that attackers will use common passwords first before starting a brute-force attempt. Even if CAPTCHA's (and other detective/preventative) devices are in place, the list of common passwords are much smaller than words in a dictionary.
I'll take a different stance and suggest that it makes sense to disallow common passwords in most use cases. The strength of a password is tied to the difficulty for the adversary to obtain unauthorized access. The qualities that the community currently accepts as a strong password are based on difficulty for an adversary to obtain access whether by brute forcing, cracking, or other methods (i.e. pass phrases and mnemonic devices increases the difficulty for a passer by to memorize). XKCD represents this pretty accurately in this comic. Using different cases, symbols, etc increase the randomness of the password such that the attack would take longer to successfully execute and also increase the likelihood that attempts would be detected.
Looking closer at attack methods, the top 25 password, along with many others are commonly populated in dictionaries. Attackers are usually keen to common passwords and will often make an attempt to run through the short list first. It's similar to the common practice that many vendors ship devices with well-known passwords (i.e. cisco/cisco, admin/admin) and not forcing the change of the well known default credentials. From payoff perspective, it's usually worth trying the common passwords first. The only reason why an attacker might not take this approach is when the attack is targeted. In which case, the attacker may exercise more caution because s/he doesn't want to throw up red flags.
Taking one step back, I use the term "attacker" loosely. Attacker can mean a bot (or automated script), a script kiddie (un or less skilled), or a skilled individual. Many security arguments muddle the ground between protecting against the auto/unskilled and skilled attacker. Though the techniques used to detect and prevent auto/unskilled attackers usually follow common sense, the skilled attacker will likely be aware of traditional detection/prevention strategies and adjust their attempts accordingly. Assume that I'm referring to the auto/unskilled attacker unless I qualify the skill level.
Following the attempt to run through common passwords, additional on-line attack methods like brute force are more difficult to successfully launch if there are appropriate prevention or detection systems in place (i.e. access logs/audit logs, brute force detection). Alternatively, off-line attack methods require access to a protected password file - if an attacker can get access to the credential info (be it hashed, encrypted, or otherwise protected). Pen testers (whitehats) often follow the workflow of using known accounts to gain initial access to a system to gain deeper access into networks. Regardless, if an attacker has offline access to a credential store, there's bigger problems than just passwords.
The practice of security really involves making tradeoffs with accessibility. The less accessible system is generally more secure than one that is more accessible. The UX/UI person will pitch stories to make their lives much easier (more accessible system). The security person will have to pitch a less accessible system. Both will ultimately have to settle on a stance that's acceptable by the BU/sponsor. Combine the previous point with the tendency for most people to place blame (or perhaps lack of willingness to accept fault) and the principle that the squeakiest wheel gets oiled first. If the user is allowed free range in choosing a password, and an attacker gains unauthorized access and wreaks havoc, the "victim" first response will be "how did this happen?" Fingers start to point all over the place and often ends up at the person responsible for security with the question, "why did you let me choose this password?" I'm not claiming that this is common, but the individual responsible for security is ultimately responsible for pursuing policies aimed at protecting the users (and brand/employer). My point here is that sometimes it's not good practice to let users make their own choice about passwords.
Then again, the value access depends on the value of the information provided and identity of the user.