I completely agree with your opinion that it is no wise idea to have phpinfo() dump your DB passwords. An ini file seems to be a little bit better, your application can retrieve the passwords when needed. With current frameworks like Symfony this is the way to go. If you restrict access to the production machines to administrators in charge you have a limited circle of persons that could access the configuration files. Of course the ini files should not get stored in a public repository. The drawback is that the application itself, your webserver user must have access to the file and thus any PHP script could read and dump it.
This raises the question of wether you are willing to make huge efforts to improve security.
In the Java EE world you can apply the following concept. You deploy an enterprise application to an application server like GlassFish or JBoss. In the concrete JDBC configuration you set a placeholder for the password. The actual password can be stored within an encrypted password file for which the administrator has to enter a password upon startup of the server. Naturally this prevents a fully automated server startup. I personally cannot assure you that this is 100% bullet proof but it makes it more difficult for an attacker.
Another possibility is to "outsource" your passwords. You could use a password service (google for "Cyber-Ark", I think they have an API/SDK to connect own applications to their password vault) tool that stores passwords and controls access. Every time your application needs a password it must be retrieved from the service. Of course, someone who gains access to the API and the login data to the password service could request passwords, too. But with a separated service you have at least the option of logging access to have an audit trail available. Separation of duties: if the password service has another administrator it gets hard for one person to do things that are not allowed, or at least there's a chance to track these things.