The "reasonableness" behind the length of time before public disclosure of vulnerabilities is not based on how long the vendor will take to fix it. It is based on the likelihood that someone else will discover the vulnerability (if not already!) and exploit it.
We must operate under the assumption that if "a good guy" has discovered a vulnerability in a product then "a bad guy" will also find it before long. That "before long" part is really just an assumption based on the best-case scenario: No one else has discovered the vulnerability yet.
Even if the vendor has no fix available disclosure is still of the utmost importance because it gives the public at large a fighting chance at remediating the problem; whether the vendor is ready or not!
Example: If a critical vulnerability is discovered in Nginx and the developers can't put out a release any time soon I can always switch to Apache or some other web server. How "entrenched" or "locked in" you are with a product is neither here nor there. That's your own damned fault if you can't swap it out with something else. Especially if you knew you were locked in ahead of time and have yet to do anything about it.
"We must operate under the assumption that if "a good guy" has discovered a vulnerability in a product then "a bad guy" will also find it before long."
Today, we have to operate under the assumption that if a good guy has discovered a vulnerability, a bad guy is probably already exploiting it.
The problem with full, immediate disclosure is its pretty easy to build an exploit for a known CVE.
Switching Nginx out in your infrastructure (for instance) isn't a simple trick at scale when you have a heavily customized install. (e.g. OpenResty with routing code)
