From a product perspective, I wonder how this would help, given this is a rather rare choice (see No-JavaScript notes on mw.org) nowadays? Imagine I'm
a) in an environment that doesn't let me activate JS. Then it's causing at best frustration with my IT team.
b) a person concerned with several side-effects of activating JS (privacy, performance). I would be frustrated that there's another feature I'd need to give up my choice in order to use. But I would not necessarily switch JS on.
c) …?

We're aiming for progressive enhancing products at the Wikimedia Foundation in general. If a product is fundamentally dependent on JavaScript, it makes more sense to hide its preference from non-JS users than showing a warning notice given the user demographics of non-JS choice.

Some thoughts,

In T194531#4759527, @Volker_E wrote:

From a product perspective, I wonder how this would help, given this is a rather rare choice (see No-JavaScript notes on mw.org) nowadays? Imagine I'm
a) in an environment that doesn't let me activate JS. Then it's causing at best frustration with my IT team.
b) a person concerned with several side-effects of activating JS (privacy, performance). I would be frustrated that there's another feature I'd need to give up my choice in order to use. But I would not necessarily switch JS on.
c) …?

I don't have any data points but my intuition tells me these cases contribute to the minority of the users. I'm not telling to ignore them but these cases don't seem to be a show stopper for this task. The majority might be benefited as they would not see the confusing message about requirement of JS even if they have JS enabled when this task gets resolved.

We're aiming for progressive enhancing products at the Wikimedia Foundation in general. If a product is fundamentally dependent on JavaScript, it makes more sense to hide its preference from non-JS users than showing a warning notice given the user demographics of non-JS choice.

Your point seems to apply to the current state beta features too. Think about how some of them might possibly miss a feature if we hide those that require JS from non-JS users. Hiding seems to be a bad thing given that a lot of features already aren't so easily discoverable. Hiding could just make it worse.

Of course, the best solution would be to develop something that also work for non-JS users. But it's not always possible. (It might be possible if we have a lot of volunteer developers, though ;-)

Removing T180538 as parent task was categorized as nice-to-have for it and not prioritized since then.