Maybe all three are, in their respective current form, good enough. Replacing them would almost certainly be a net loss.
Standards are made by first-movers even if what they move is howling junk. Every technology has been immature when first brought to market. What we need to be looking at are the obstacles to maturation, which seem to be increasing.
That kind of answers your title question. Without a contender, there's nothing to replace them with. I do agree with the rest of your comment, though, it'd need to be something that could be implemented and used in parallel with the existing standards. Ideally something near isomorphic to them so that browsers can mostly just do a translation to get a good enough initial implementation, and then refine it over some iterations if the underlying HTML/CSS/JS models don't cover all the things in the new system.
Also, are you meaning a contender would replace all three with one new language, or would it be three new languages that are (somehow) better than the three existing languages?
Each language fits a different niche. Assuming we're not going the Gemini "baby with the bathwater" approach and are retaining the capabilities of all three (more or less), you'll need three sub-languages that fill the three roles.
HTML is a content markup language and has, over the years, drifted increasingly towards being a semantic markup language (not full-on semantic web markup, but not the rather anemic semantic model it could describe 30 years ago). We've separated the formatting/layout to CSS for a reason, though you don't actually need CSS files or even <style> tags unless you want them. You can embed all that in the HTML elements as attributes. However, we separated that out (as an industry) for a good reason, if you embed it into the elements you have to update every page when you want a uniform change. That's a PITA, so you'll end up with separate markup and formatting anyways, at least if you want people to use your language for anything more than one off pages. And if you want adoption (and not the extremely low adoption of gemtext) then you'll end up doing this.
So you have two languages, content markup and formatting/layout. You can mash them together to be "one" language, but it'll be two sub-languages that aren't really the same at all, and we're just splitting hairs.
Then you get to JS. Its role is to be the procedural language giving you dynamic changes to the content and layout/formatting. You could make a declarative language for this, but those are (apparently, based on adoption) harder for people to reason about and use than conventional procedural languages. This gives us a sharp divide in our one language between the declarative portions and the procedural portion. And, again, you'll want to separate out this dynamic portions from the more static portions for better reuse.
In the end, you will likely have three separate file types even if they ostensibly contain the same language. You'll have content files, formatting/layout files, and dynamic content files, and some mechanism of including them into a page for rendering. And each will be described using a different sub-language of your one language.
This puts us right back where we started, but now we have 6 standards (ignoring the fact there are multiple versions of HTML, CSS, and JS already) instead of three.
So that brings us to the only way to move away from HTML, CSS, and JS that has a chance at actually replacing them: Three new languages that each fill the same roles as the current languages, but do it better. Potentially with greater uniformity of design between the three languages, but the sharp divide between the declarative HTML/CSS replacements and the procedural JS replacement will make this a very challenging language design problem.
----------
All that written, if you don't care about replacing them, you absolutely could do a weird mashup language and ignore all the reasons for separating the three out. You just won't get adoption outside of a niche community like Gemini has developed around their restricted formats.
The first answer that I have is that it's an accessibility reason. All the technologies that you have mentioned are accessible. Everybody can learn, integrate, and implement and most importantly, they are fast to deploy. I think that it's also a universal language that everybody can speak. If all of a sudden everybody changes the tech stack, everybody will have just to learn a new paradigm to create websites.
Another thing that I might even consider (but this is something that is very much vague even to talk about), but I want to throw it out. I think there is a certain pride in creating so much code that it's still used even to this day, so replacing it is like saying that all my lifetime work just vanishes away. As I said before, this can actually not be the case. In the end, we are talking about things that are mostly static.