Idempotency is a crucial trait in the world of web APIs (and any other system where commands that modify state might need to be retried due to communication failures). It's not a new word or concept, but it's certainly a niche one.

I think you're conflating general "boringness" with tech-specific features. Test driving solutions is useful but it tells you nothing about reliability.

Say it's 2012 and you need a new car. Toyota Corollas have generally proven to be incredibly reliable. The Tesla Model S is brand new: definitely not boring. On paper both meet your needs, so you test drive both. The Tesla is way more fun to drive, and that's appealing, but if you just want your car to work for a long time with predictable maintenance, you should take the Corolla.

Choosing the most appropriate tech is not mutually exclusive with choosing boring tech. In fact, "boring" (well-known, battle-tested) is very likely the most appropriate because it reduces unnecessary risk.

I'd welcome the ternary conditional operator but I hope exception handling never gets introduced (at least as I'm used to it from Java, C#, JS, etc.).

Exceptions should not be conflated with regular error handling, especially when they're allowed to bubble up from anywhere. I very much appreciate that functions that can return errors force the caller to deal with them, for the most part. True exceptions can already be thrown with panic, although I actually find it incredibly rare that I need to reach for that tool. I'd argue that when people talk about exceptions they almost always actually want "unhappy path" error handling.

Now, if Go wanted to add a sleeker way to handle those errors, similar to Rust's approach, I'd be very interested. Minimum three lines for every call to a function that returns an error does get a bit verbose, arguably hurting readability. A little sugar could improve readability without making error handling implicit.