No, it's not reasonable to apply P0's public vulnerability research norms to internal security research.
P0 "competes" on an even playing field with everyone else doing public vulnerability research and, to a reasonable approximation, has access to the same information that everyone else does. Internal security assessment teams have privileged information not available to public researchers, and rely on that information to get assessment work done in a reasonable amount of time.
When P0 discovers a bug, it has (again, to an approximation) proven that any team of researchers could reasonably find that same bug --- everyone's using roughly the same sources and methods to find them (albeit P0's are done at a much higher level of execution than most amateur teams). That's the premise under which P0 bugs are announced on a timeline: what P0 has done is spent Google engineering hours surfacing and refining public information.
If you want to go a little further into it: the 90 day release window has a long history in vulnerability research. It's the product of more than a decade of empirical results showing that if you don't create a forcing function, vulnerabilities don't get patched at all; vendors will back-burner them indefinitely. Google's internal teams don't have that problem: when Google bugs get found by internal teams (and, presumably, by external ones), they get fixed fast. There's no incentive problem to solve with an announcement window.
Another lens to look at this through is the P0 practice of announcing after the publication of patches, regardless of where the window is. That's because, again, P0 is doing public research. Typically, when a P0 bug is patched, the whole world now has access to a before/after snapshot that documents the bug in enough detail to reproduce it. At that point, not announcing does the operator community a disservice, because the bug has been disclosed publicly, just in a form that is only "available" to people motivated to exploit the bug.
And again: not at all the case with internal assessments.
P0 "competes" on an even playing field with everyone else doing public vulnerability research and, to a reasonable approximation, has access to the same information that everyone else does. Internal security assessment teams have privileged information not available to public researchers, and rely on that information to get assessment work done in a reasonable amount of time.
When P0 discovers a bug, it has (again, to an approximation) proven that any team of researchers could reasonably find that same bug --- everyone's using roughly the same sources and methods to find them (albeit P0's are done at a much higher level of execution than most amateur teams). That's the premise under which P0 bugs are announced on a timeline: what P0 has done is spent Google engineering hours surfacing and refining public information.
If you want to go a little further into it: the 90 day release window has a long history in vulnerability research. It's the product of more than a decade of empirical results showing that if you don't create a forcing function, vulnerabilities don't get patched at all; vendors will back-burner them indefinitely. Google's internal teams don't have that problem: when Google bugs get found by internal teams (and, presumably, by external ones), they get fixed fast. There's no incentive problem to solve with an announcement window.
Another lens to look at this through is the P0 practice of announcing after the publication of patches, regardless of where the window is. That's because, again, P0 is doing public research. Typically, when a P0 bug is patched, the whole world now has access to a before/after snapshot that documents the bug in enough detail to reproduce it. At that point, not announcing does the operator community a disservice, because the bug has been disclosed publicly, just in a form that is only "available" to people motivated to exploit the bug.
And again: not at all the case with internal assessments.