I had something like that on an internal system. The 400 rate would jump all over the place because our edge systems had shitty input validation, and bots would crawl us with broken requests ("can I reserve this item starting last week?" kind of thing) with no rate throttling. After a few years the edge validation (and bot detection) got better, but alerting on that would've been worse than useless.
It's easy in retrospect to say "oh that was a waste of time because it was just bots" but you don't know that until you investigate. I ask myself "if I see elevated 4xx's, at what point do I start to care if they're caused by a bug?" and set monitor thresholds somewhere around there.
Its empathetic to keep an eye on surges in 4xxs
Cover mistakes with robust probers that should get 200 and then alert on any non-200 response.
This is bad general advice. HTTP 4xx errors mean the client screwed up, OR you screwed up (a change that e.g. increases 404 rate due to eventual consistency, returns 404 for all content, breaks auth, returns the wrong status code, etc.). Either way the content is inaccessible to the client, the person visiting your website doesn't care if they get a 404 or a 502, they care that the content is inaccessible. Once you get high enough traffic, monitoring 4xx rate is pretty critical to making sure people can actually use your service. (Or monitor the inverse, i.e. a floor on 2xx rate instead of a ceiling on {4,5}xx rate.)