Part of the problem with open sourcing Google's software is that the software is often integrated with a bunch of the rest of the google stack. This could just be dependencies on little libraries that may or may not already be open source, all the way up to depending on various large components to do some of the heavy lifting around security/scheduling/storage etc.
If some library (that the thing being opened up uses) has an open open source version, it is necessary to worry about versioning concerns, because unlike inside google3, the open source versions can no longer make breaking changes merely by updating every single consumer. So the internal version in some cases will have drifted from the open source version. Even when a library or tool needed is already opened sourced, it is not rare for a newly open source program to use a stub version instead of the full tool/library to avoid such headaches. (e.g. I've seen super stripped down alternative to gtest shipped as part of some opened libraries, because trying to utilize the open source version was more hassle than it was worth.)
For libraries or tools not open sourced, some form of stub or adapter to some similar publicly available software is needed. In some cases that does not exist, making directly open sourcing basically impossible (but redeveloping the tool might be possible). In other cases there are alternatives available, but they might be lacking features that made the integration nicer inside Google.
Overall I can totally understand why Googlers sometimes want to basically redesign an internal tool as the approach to open sourcing the underlying concept, rather than try to publish the equivalent-ish internal tool.