In most cases properly selected defaults can be a huge win. They save a lot of time and often ensure that whatever application you are creating does the right thing in the absence of user input.
There are, however, cases where I believe that default values should be actively avoided because the downside of bad behavior far outweighs the convenience offered. Most of these cases have to do with anything related to the deployment and maintenance of customer facing software.
I strongly agree with the idea that software should fail quickly and loudly. Often software that appears to be working but is doing the wrong thing can have more harmful outcomes than software the fails spectacularly if something is wrong.
One example I have seen of this is with database connectivity. In many organizations, the production environment is treated with a bit more care and reverence than the development and testing environments. As such, some of the safeguards that exist in production environments, such as proper networking to ensure that only the appropriate resources can communicate with each other, rotating or dynamic keys and credentials, properly created and utilized certificates, etc. are not strictly followed in these lower environments. Because of this, resources are sometimes able to communicate across environment boundaries and this has led to some bad behavior. A default database connection gets set for a service or application for the sake of expediency. As development and testing continues, all is well since the software is correctly doing what it should. Then it gets promoted to an environment for testing. It still appears to be acting correctly, because the software can still actively communicate with its needed resources. All the tests are passing, everybody is happy. Ship it!
As soon as the production environment is updated exceptions start getting thrown, highlighting database connection errors. The new feature your customers have been looking forward to is broken on arrival. If all goes as well as it possibly can in these circumstances, the error is quickly found, the configuration updated and the users can get on with their lives. If this feature is soft launched, or not a lot of people use it, or your monitoring and alerting is not up to par this can be deployed and the error can go unlooked at for an extended period.
And yes, I know there are a LOT of things wrong with the above scenario. But some of these conditions exist in real life for a wide variety of reasons. If you really care about the values for a piece of software, or the downside of bad behavior is large, consider NOT setting a default value for that parameter or attribute