(The actual answer is: I have no idea what Google does with JWTs.)
Which minimizess the number of things you need to get right or in your words equals more secure.
Designing a token that can be validated instead of looked up. (Design/Implement once)
Or
maintaining, updating and monitoring a set of firewall rules so that app-servers in network zone x and y can make call backs to a database in network zone z.(design many implement many)
There are a ton of great reasons to use JWT at scale. As with anything use case is important.
I'm almost certain it's a bad idea if that means rolling your own Kerberos implementations in php, javascript and golang in order for your various back-end to speak to your various front-ends.
But sure, leverage secret-key crypto and tickets in your own implementation in a way that's more secure than Kerberos.
Or, use a solution that's simple enough any weakness is fairly obvious.
Yes! This is the answer to almost every "Well, it works for Google..." that comes up.
Alice: "It works for Google!"
Bob: "Sure, but how many PhDs does Google have on payroll managing it?"
Google has the resources, meaning dollars and reputation, that if they want to do something, they can hire anyone they want to make it possible. They frequently hire the authors of the programming languages and environments they use (that weren't already invented in-house), who can then customize everything to fit Google's needs just so.
Assuming you're a normal mortal corporation, getting the inventors of your platforms on board and committed to your problems specifically is no trivial matter, and you don't have an army of bona fide, credentialed computer scientists on payroll to patch any intervening rough spots, so "Google does it" is not really applicable.