I feel like it's not something I would recommend to someone that wasn't already very comfortable implementing and evaluating cryptography designs, is where I'm coming from. Key commitment is a pretty corner-casey problem. If I was designing a new competitor to AWS KMS, I would take it very seriously. If I was encrypting a cookie, which is, like, the modal and most representative motivating problem for authenticated encryption, I don't think I'd much care about it at all.
The thing about commitment is, there's been a bunch of writing, and, especially, a bunch of conversation about it amongst cryptography nerds. It occupies a sort of similar space to KCI attacks. Like KCI, there are settings where it matters, but (1) even in those settings the attacks tend to be second-order things, and (2) those settings are kind of rare and specialized. But like: all the more important attacks on cryptography are basically solved problems! So this is what crypto nerds talk about.
It doesn't follow from that that these are problems that should be top-of-mind for people building normal systems.
I would not talk someone out of using Golang Seal/Unseal just to avoid KCI. I might talk about appending zeroes before I talked about hand-rolling an EtM just to avoid that problem.