For each rule in isolation, that's true enough. But the point stands: once you add together all those good practices (repetitions, consecutive letters, multiple character sets), how much does that actually reduce the password space? I'm not saying that the space becomes tiny, I'm saying that it becomes smaller, and I'm not sure whether "smaller" is still acceptably large, and it's an assumption that's worth checking.
The cost in entropy for these restrictions isn't zero, but it's tiny and measurable.
As a conservative estimate, let's assume passwords are only chosen from a set of 84 printable ASCII characters and users never choose passwords longer than 10 characters. (If users are using characters outside this set or longer passwords, they'll have more choices than we're estimating.)
All combinations, including the null password yield 17700847248605297701 combinations, or 63.94 bits of entropy if a password is chosen truly randomly from this set.
Restrict them to passwords at least 7 characters long, and that drops to 17700846893074759680, about 1.9e-9 bits less, still above 63.94 bits.
Further add the restriction that no two adjacent characters are the same and that drops to 15894480881247564960, or 63.78 bits.
Further force the user to use one digit and that drops to 11477476711812418840, or 63.32 bits.
For the sake of my time, I'm going to get a bit sloppy and start over-estimating the cost of restrictions. Further force the user to have at least one upper-case and one lower-case letter and that drops to (more than) 10727550596265784840 passwords, or 63.22 bits.
So, all of these restrictions together cost less than 0.72 bits of entropy. That an easy price to pay for eliminating large classes of trivial passwords.
Thanks for doing my "homework" for me :). Interesting, I seriously expected the repetition and adjacency restrictions to add up to a much bigger cost, to be honest.
