The main argument for a fixed deadline is probably that history shows that many vendors will take ages to fix software if no hard deadline is set for disclosure. Since it is likely that others will find the same bug too (or have already found and use it) this means that users are at increased risk without being aware of it. This also means that they will not add additional defenses to deter the risk, like increased monitoring, replace affected software with a more secure one, or reduce the risk by temporarily taking affected systems or services offline.
The main argument against a fixed deadline is that some bugs are more hard to fix than others and thus fixes take more time and that maybe there are no effective workarounds for the customers. Thus customers have an increased risk while the vulnerability is known to the world and thus potential attackers but no fixes or workarounds exist. But at least they can be aware of this additional risk. Past has shown that if this is the case it is often sufficient if the vendor works closely with the security researchers to get the problem fixed as fast as possible. And if past experiences with the vendor where positive the researchers often extend the deadline a bit this one time.
Regarding the Google Zero Project: one might complain about their hard deadlines but if you look at the work they do and how fast most vendors react to the bugs found the strategy of a hard deadline seems to be successful: many bugs are fixed within a few days, i.e. much shorter than the deadline. And I very much doubt that this would be the case if the pressure of the deadline was not there.
