Pretty much this. I was very anti-REST back circa 2015-2017 when I started doing web dev. I was doing solo work and all my services were JSON-RPC (I can't remember whether that was an actual standard then or if I just rigged it). I was (and still am!) into functional programming, and RPC seemed to fit better: it's just a remote function call. Nakedly PUTting a resource just seemed to violate my idea of good architecture.

In 2017 I left to join Azure, which is REST-heavy (in all this, I mean "modern" REST, not "Fielding" REST). I hated it at first, but eventually saw how nice it is to have the conventions. Less to explain in public API docs, easier to generate scaffolding, common themes of how to destructure incoming requests in middleware handlers and middle-tier services, a standard way to serialize references to resources across the platform. I was a convert.

Moving to google in 2021, they're still very RPC, and it feels so cluttered and arbitrary. I'm not there anymore.

Yes, REST is roughly just some conventions around RPC at the core (though you get things like caching for free), but ultimately it's a really nice set of conventions that are easy to follow and limit surprise, and are standard across the industry. As one user commented, you do sometimes have to work around REST to get it to fit, typically futzing in headers or request metadata, but to me the pros outweigh the cons.