I see harvested passwords as a larger threat than bruteforcing, so some kind of expiry is important. Some users might use good, unique passwords, but most will not.
I make the assumption that the longer a password exists, the more likely it's reused and compromised. I don't have insight into every password dump, but I know my users reuse passwords a lot. I think a long expiry is the best balance in my environment.
If if you did a 1-year password expiration, and last year's passwords were compromised, then if the attacker figures out that someone's password last year was "uwethskjv9j29#18", then there's a good chance that the attacker is going to try logging in with the password "uwethskjv9j29#19" this year and "uwethskjv9j29#20" next year, and will probably succeed.
You gain nothing from password expiration, other than annoyed users and and even more annoyed IT team who has to deal with lockouts from people that changed their password to something secure.
More significantly, if changes are required or weird composition rules used, people are more likely to store their password in a convenient unprotected form (historically, often paper kept next to their main computer, which is a risk, but these days the convenient form may itself by subject to remote compromise, making an even bigger risk.)
I often hear that attackers will simply increment the number at the end of your password, but users apply many different "simple" changes and it's likely that you'd need to try a fair few tries to guess correctly. That might be feasible if you have the new password hash or you're targeting an individual victim, but if you don't, then the password expiry policy offers some defence in depth.
You require new passwords every year, done Require symbols, done lower and uppercase, done numbers, done