What are the risks associated with the different disclosure philosophies, if there are any,
there are, the most known ones are informing the company and wait, informing the company and disclosing it or simply disclosing it. depending on the "color of hat" youre wearing can make this decision easy.

and which problems can you see with one or the other?
being the white hat that i am, i would always inform the company/person who owns the software first, and give him a time window (depending on the complexity of the vulnerability) to fix it. after that i would disclose it to the "scene". The only problem that occurs is that most companies dont appreciate the effort you took to hunt down the vulnerability. this can lead (depending on the country) to lawsuits and everything that comes with it.

Would you agree to the statement that responsible disclosure is only appropriate when doing a hired pentest for a client and not from an individual's perspective?
in an ideal world this would be the way to discover vulnerabilities. the problem that is addressed here lies with the average quality of software that is being produced. once this is taken care of (and again in an ideal world security would be implemented througout the whole development process) the only reason to do a pentest would be to check if all security measures are taken and all the settings are correct.

It's a tough subject, I think.   In most cases, I would favor full disclosure to the software developer, and limited disclosure by the software developer.  This would allow the software developer to release a brief statement regarding the vulnerability, hopefully with just enough information for its customers to adjust their IDS to detect the new attacks.   As a software vendor, I would not release the full details of a vulnerability.   

However, sometimes, software vendors downplay or ignore the vulnerability.   Full disclosure to the public can force the software vendor to fast track a patch.   

It depends :-)

I have a multiple-personality disorder on this topic.
On one hand passing the information to the vendor to manage responsibly always appears to be the best, ethical approach.

Then this is where the voices kick in:
What if the vendor has a bad track record or will take months to fix it?
What if this is really impacting the security of a core system?
What if you see this vulnerability being used a a live exploit?

If I know a vulnerability exists I can plan for it and provide mitigation or have someone smarter tell me have to make my system safe.

Given the scenario I hired you to test my systems and during that test you discover X vulnerability in a piece of my network, let's say you find the recent VMWare directory traversal issue, you report that. It should be my job to pressure the vendor to fix what you found and for them to provide mitigation in the meant while.

In the scenario I found a vulnerability, I'd contact the vendor, but also reach out to a couple of trusted industry groups or people to act as proxies. This would heavily depend on the vendor and their reputation. If I got burnt by the vendor, then human nature could dictate that you take a more direct method next time.

I can understand the concept of by-passing a slow or unresponsive vendor and publishing the vulnerability to the unwashed masses of the internet. Does it make for a faster resolution by the vendor given a massive public outcry? Some Microsoft out of band patches releases may lead you to believe that is the case.

I'd hope that people would act in the communities best interest and not be motivated out of ego. This does conflict with telling the vendor first, but what measure of respect do you give a company willing to put out bad code and refuse to fix it over hundreds of thousands of people suffering lost or exploitation of their systems?