I'm glad you had that experience with Go readability, because mine was far from that. Java readability taught me loads. Go readability taught me almost nothing and took far longer. In the end I was given it when I emailed the admins to say "either give me some feedback or give me readability". I'm fully behind the readability concept, but it's hard to scale and keep the quality high.
The predictability of the process was not particularly amazing. I just didn't set my expectations very high; with Python and Java... getting readability was on my first quarter OKRs and I accomplished those (my Java readability reviewer was on my team so it was pretty easy). Go... took a while.
I have never been quite sure that that's exactly where you want to draw the line. I've been in the position of having a team that's relatively new to Go, and despite being a straightforward language, there's a lot of things you can do, if you know to do them, that makes the code significantly more reliable. I couldn't review every PR on my team, so sometimes stuff slipped through that caused An Incident and it bugged me because a simple "do this instead of that" would have prevented The Incident.
I asked some other senior folks that had worked at Google "should we do something like Readability" and the answer was a unanimous "absolutely not, no, never" so clearly other people fell more towards your views than mine. People do just want to get their stuff checked in and go home, which I respect. Someone else is then going to have to go to a bunch of calls with customers when it breaks, though. Guess who that was and where her views are on the matter ;)
