TBH in modern code one should avoid Number() because it performs a weak coercion to number. For example Number(null) === 0, Number(true) === 1, Number('Infinity') === Number.Infinity, Number(' ') === 0.

Instead using parseInt/parseFloat is much preferred because they only accept strings and don't do weird things like coercing whitespace-only strings to 0, or parsing Infinity to the global Infinity value - they are all around much stricter.
They also strictly typed to only accept strings - meaning TS will error if you attempt to do something like parseInt(0).

I'm not 100% sold on this being something that's of great value given the above and given that step 1 of the number coercion algorithm is "if number return" - so it will be super low cost to have useless Number()'s in the codebase.

Would love to hear more feedback from others (cc @JoshuaKGoldberg).

This perhaps not only applies to Number() but also report unnecessary parseInt/parseFloat?

@kkmuffme you can't really have an unnecessary parseInt/parseFloat because they are typed to only accept string.
So the only way it could be unnecessary is if you pass a string literal or regex literal typed value that clearly would make the function return NaN.

Maybe a general-purpose rule for unnecessary Boolean(...), Number(...), String(...), and similar? I'm mildly in favor for this, but not very passionate about it. 😄

On MDN, I'm always slightly in favor of Number(). parseInt() does not allow 0x/0b/0o prefixes, and its behavior of automatically ignoring invalid suffixes may not be desirable. If JavaScript is going to implicitly coerce your string to a number, it uses the same algorithm as Number() anyway, so I think the consistency of using the same coercion algorithm is more desirable than debating whether Number("") should be NaN or 0. (BigInt("") also returns 0n—that's another argument for consistency.)

@JoshuaKGoldberg yes exactly, that's what I had in mind originally too.

@Josh-Cena agree with that

parseInt() does not allow 0x/0b/0o prefixes

How often do you need to parse input that's possibly in any of the valid, fully-qualified bases?!?
Like - I get that it might be nice - but I don't know of a case where you would actually want that behaviour aside from some super niche dev tools.

Personally I can count the number of times I've written something other than parseInt(str) / parseInt(str, 10) on one hand.

It's been a month and this issue has garnered no additional reactions or comments from the community. As such I'm going to close and reject this from the plugin, as it does not appear to represent a problem the wider community is interested in.