The primary reason that Bitcoin Core doesn't use OSS-Fuzz is that as Greg Maxwell states in this secp256k1 issue, there is an:
extremely short timeframe mandatory disclosure (edit: 90 days) which basically made anything except blindly installed automatic updates a viable way to deploy fixes
Pieter Wuille adds some additional context here:
This extraordinary requirement for exact consistency between implementations means that these classes of issues cannot be fixed in the time scale of software releases, but requires network-wide coordination. The most relevant example is how a platform dependent deviation from the DER standard in OpenSSL threatened a network split a few years ago; you can read about the issue and its timeline here. In that case, it took 9 months between discovery and eventual resolution, but I believe that similar issues these days would take significantly longer still.
Without a future exception granted by Google, Bitcoin Core using OSS-Fuzz is a non-starter.
I am less clear on exactly how much additional value Bitcoin Core would get from using OSS-Fuzz in a theoretical world where Google granted that exception. It is partly discussed in the issue in addition to the current state of fuzzing in Core and the secp256k1 library.
There is also the consideration of dependence on a specific corporation's infrastructure. Open source projects aren't locked in to OSS-Fuzz but it is generally time consuming and disruptive to make the transition off of them.
Update on May 5th 2021: Bitcoin Core has signed up to use Google's OSS-Fuzz.