Confused about using a password that "would take centuries to break"

Confused about using a password that "would take centuries to break"

I am talking about this password - 23##24$$25%%26 and the similar ones consisting of special characters appearing in a pattern, which the users these days use a lot.

At work (finance company), I was creating a list of bad passwords that users should not be allowed to choose, involving certain cycles or pattern, and the above kind exhibit that trait of containing consecutive numbers sandwiching special characters (repeated certain times, here twice).

Just out of curiosity, I checked this on a very well known website (on its login page), and it stated that this would take centuries to break.

Some more examples in the list which would take years to break, but are highly vulnerable:

1!2@3#4$5%6^ 2@3#4$5%6^7& a!b@c#d$e%f^

Now, I stand confused with the list, should I mark these particular kinds of passwords as vulnerable and disallow the users going for them, even if they take a very long time to break?

Note 1 - We are considering these vulnerable as many users (and, hence, multiple similar passwords) are following this trend to remember things easily.
Note 2 - We are confused because the security guys are all about increasing the entropy, what they are ignoring is an increased orderliness of similar hashes in the database
There arose a friction between guys as to where we draw a line, defining which password be allowed or disallowed.

Edits:

• This website I am talking about, but won't name, on which I tested the password is pretty much known to every ethical/unethical hacker, almost every user here on Stack Exchange and many big/small companies (as they use its services).

• We do not store passwords in plain text. We use a nice, not home-brewed, hashing algorithm.
  An incident led us to review our password policies, and we created a separate database db-2 on a different machine, wherein we stored simply_hashed_newly_created user's password (no salt, nothing, just hashed_password) without storing who_created, when_created details. We did this for short period only. Any password change too went into this database. While, in our original database db-1 sat secure_salted_passwords.
  We kept creating a list L of hashed vulnerable passwords as well, following a pattern, and we were left amused when we matched L & db-2 - we saw multiple groups of similar passwords, with certain patterns. L and db-2 were later erased from the systems.

• db-2 was kept on a highly secure machine and was safe, won't disclose the exact details here. We are aware that even air-gaps or electric-sockets aren't secure. Both db-2 and L were destroyed.

• Worry not about passwords posted here, as we have already conducted our small experiment, and all those specific set of users have been made to reset their passwords (of course, a new password different from the old one). That's the reason, I came here posting few samples.
  And, I have commented here earlier too, that I posted a sample of passwords from the generator's logic which created a very huge list of hashed passwords, which may or may not be in db-2. Again, since all those users have a new password, so no worries, everything is safe and secure.

• Since I know the generator's working, I tested few password-samples on a website, and we got confused over which ones to be allowed or disallowed, over what criteria.

Thanks a lot for your answers, accept my gratitude. Based on the answers, for the time being, we have postponed any kind of restriction to be put over password's choice.