Personally, I would like to work on implementing this plugin, but is this an appropriate rule to incorporate into ruff?

I know there were objections to the introduction of this operator, but I feel this rule is a matter of user preference.

What's the rational of forbidding the operator (other than lol :D). Is it useful to a broad audience of the Python community?

The objection is readability. It may not be the only one, but it is mine.
I totally see that it is somewhat of a nice QoL feature, but I and others too do not want to exchange readability for 1 line of code saved.

And I do not want others to be able to use it in code I maintain, so I forbid its usage via the flake8 plugin by running flake8 in CI.

It is totally subjective preference but so is any style rule somehow, is it not?
But in comparison to PEP8 it is rather niche I guess. So I can see why one would not want to implement it. But nontheless I and probably others too would like to have it being implemented. 😉

Yeah, I think this is a hard one for us to merge until we have a clearer policy on opinionated rules / plugins (similar to #3463).

It is totally subjective preference but so is any style rule somehow, is it not?
But in comparison to PEP8 it is rather niche I guess. So I can see why one would not want to implement it. But nontheless I and probably others too would like to have it being implemented.

Thanks for explaining your motivation.

We're considering reorganizing the ruff rules and one category that we intend to introduce is restriction. Rules in the restriction category are opinionated, not recommended for most users, and restrict the allowed language feature. I could see this rule fit into that category if it satisfies the criteria that it is useful to some community users (we don't want to have "I don't like" rules, where I is a single person).

The restriction category sounds very nice. I think this will be a very good way to separate those special rules.

Sure, when e.g. I am the only one using it, I would have to wait for plugin support and write my own plugin for this. This makes sense to me.

#13741 is related where the author asked for restricting most, but not all walrus operators.