First, the non-security reason:
Password Change Workflow
Passwords change independently of a software application code. If a DBA changes a database password, does it make sense for developers to have to update the code, get a new build and release to production, and try to time it all? Passwords are a runtime configuration artifact, not development artifact. They should be injected via configuration files, environment variables, or whatever configuration paradigm you are using.
Generally, version control systems provide authorization control so only authorized users can access it. But within a repository, permissions are generally either read/write, or read-only, or possibly some bells and whistles like GitHub provides. You're unlikely to find security constraints that let developers get source code, but not passwords. If you can clone a repo, you can clone a repo. Period. In many environments, developers don't have full access to production. Sometimes they have read-only access to production databases, sometimes no access. What if developers do generally have access, but you don't want all of the interns, new hires, etc. to have access?
What if you have multiple environments, like a development environment, QA environment, staging, and production? Would you store all of their passwords in version control? How would the app know which one to use? The app would need to have a way to know the environment, which would end up being a configuration setting. If you can make the environment name a configuration setting, you can make the database password a configuration setting (along with the connection string, username, etc.)
As others have mentioned, version control is designed to preserve history. So older passwords will still be retrievable, which may not be the best thing.
How many times have we seen headlines in the news about source code for some product being leaked to the world? Source code is whatever is in version control. This is probably the top reason to not put passwords in version control!
That said, passwords need to be stored somewhere. What the above concerns are alluding to is not necessarily that they shouldn't be stored in version control at all, rather, that they should not be stored in the product's source code repository in version control. Having a separate repo for config management, operations, etc. is very reasonable. The key is to split operations from development when it comes to security credentials, not necessarily to avoid version control altogether.
Also, for non-production environments, I've stored passwords and API keys for external systems in configuration files within the product source code as defaults. Why? To make it painless when a developer checks out the code, they can just build and run it and not have to go fetch extra config files. These are credentials that rarely change and do not lead to any trade secrets. But I would never do this with production secrets.
So the bottom-line is... it depends.