openstreetmap-carto is the face of OSM. Over the years, it has managed to occupy an uncanny valley. Everyone – mappers and casual end users alike – perceives the map as something primarily intended for their use case. Any omissions seem like glaring oversights rather than careful compromises. I haven’t fully digested Christoph’s blog post, but it is helpful for understanding how he thinks about the space osm-carto occupies in the ecosystem. If the post had been published some years earlier, maybe it would’ve helped to set more realistic expectations.
We like to tell laypeople that OSM is a map database, but often that flies over their heads and they don’t share our enthusiasm about contributing to one. If we simply take away the Standard layer, they may no longer mistake OSM for a map product, but they’re no closer to understanding what makes OSM such a powerful concept at first impression. If we replace the Standard layer with a browser ballot of sorts, then someone who doesn’t understand the common thread among these choices will perceive the site as basically a map gallery, which is even further from what we’re about.
I don’t think we’ll have a very satisfying solution until we get to the point where osm.org renders vector tiles on the client side. In the vector tile world, the client-server architecture is optimized for more visual variety. If someone wants a niche POI type labeled on the map that no one else wants, we can genuinely suggest a fork instead of handwaving about one like today. As long as that fork is compatible with a common tileset, server load is a nonissue. There could even be some dynamic, personalized options. It’s no panacea, but it takes some of the pressure off the designers in charge to balance all the competing interests perfectly. At least the complaints will be distributed between the client-side style maintainers and the server-side tileset maintainers. 
By itself, migrating to vector tiles doesn’t fundamentally change a layperson’s impression of the project’s purpose. But a completely different-looking style could have that effect. Vector style designers already rely on an inspector or “X-ray” mode for understanding and manipulating the data within vector tiles. Similarly, OSM has long had an interactive Map Data mode, hidden away where most users wouldn’t find it. Just as well: the overlay hammers the OSM API and bogs down your browser. Most people would probably prefer to blindly click around using the Overpass-powered feature querying tool instead.
Vector tiles would let us rethink the Map Data mode. It could perform just as well as a “human-readable” map and offer much of the same information immediately on hover. It would be functional at low zoom levels (thanks to filtering), and giving it an industrial chic aesthetic would require relatively little effort. We could make it the default style or put it just one click away, similar to the satellite toggle on most map sites. This too could be the face of OSM, one that unabashedly celebrates the intricacy of our data while serving as an efficient debugging tool.
If you’re looking for a straightfoward drop-in replacement for osm-carto, I’ve got nothing. But concrete efforts are being made toward vector tile infrastructure, so that’s what I’d invest my patience in.