I'd argue the opposite about rate limiting - If you can add it in a way that allows 95% of valid use cases to never run into it, but stops broken implementation

I'd argue the opposite about rate limiting - If you can add it in a way that allows 95% of valid use cases to never run into it, but stops broken implementations and bad actors from degrading your service, it's a net win for your clients. I agree it should expose a lot of information though. There's nothing worse than an opaque rate-limit where you can't even predict how to work around it in your code.