I think the part that is missing here is that you were called upon to 'fix' the database, which you are not officially supporting. I have been aware of many installations at various organizations (mostly in development groups, but not all) where the DBA is truly called in only when problems occur. My group didn't have the manpower to support everything, and management made the decision that these other 'rogue' installations were OK. Yes, we were called in when problems existed - but after fixing the problem (and sometimes that might even mean a full SQL reinstallation and data loss depending on severity) we walked away. Our being called in to fix the problem did not mean we should be bringing it up to standards, installing standard maintenance, or anything else which "normal" support would entail. These SQL instances were not meant to be robust, or they would have fallen into our "fully supported" mode, with full DBA oversight.

Ultimately, it is up to management to decide where SQL resources like DBA labour hours are spent. If they decide environments exist without full DBA support, there is typically a business reason. It is that separation of authority and responsibility mentioned before. You cannot assume or be assigned responsibility for environments that you do not have the authority to manage.

While it is risky, sometimes management and the business makes that decision for some environments. At that point, all you can do is fix the immediate problem, point out any ongoing risks you see (without fixing them), and hand it back. Doing more is going beyond what you were asked and authorized to do. Doing less is not being a professional and giving management the visibility to any additional risks they might be incurring by having the database outside of full support. Sometimes this has been enough to bring the system under full DBA support - but that is not your decision.

Sometimes you just have to live with that. I loved the "clown car" tag as well!!