FWIW, there's never been anything resembling official criteria. In practice it's more of a "can you convince people that there's a significant benefit to putting it in std instead of a crates.io crate?", and 99% of the "X should be in std" threads that pop up around here never come close to clearing that bar.
As far as extrapolating some unofficial but nonetheless informative de facto criteria based on what's actually gotten into std historically, I don't think much has changed since I wrote this:
Typical compelling arguments for putting things in the Rust standard library include "vocabulary types" (e.g. the whole Rust ecosystem needs to agree on a single
strtype just so everyone's code can talk to each other), code that needs to interact with the compiler in some magical way, or tricky unsafe operations (because we truststdverification more than 3rd party crate verification, though even that could potentially change in the future), or platform abstractions that help keep a lot of Rust code portable-by-default (though that strategy didn't scale as well as we hoped, so that might change too). All of these are pretty fuzzy and case-by-case criteria, not remotely official in any way. In fact, in the specific case of an HTTP server, there is an obvious vocabulary types problem, but the ecosystem ended up agreeing on a 3rd party crate for that and AFAIK no one's ever asked for it to be moved intostd.
The main thing I left out there which is probably noteworthy in this discussion is "tiny things that nearly everyone would find useful but would never import a crate for", which is very rarely a successful argument, but the poster child for succeeding that way is the dbg! macro. IMO that's the most relevant precedent to compare against, at least for the "is this worth putting in core/std?" question.