Agree. I see a lot of comments here on Codewars with folk saying "use <xyz> it's faster" where one or more of the following are true:

• There's no stated performance constraint
• The "faster" code is less readable or maintainable
• The code is extremely unlikely to be a bottleneck in any real implementation
• The "faster" code isn't actually faster at all

To that last point I profiled this kumite just for a laugh, running this version and the previous over an array of 10 million random integers. Here's a typical case:

Created array of 10000000 ints in 22.663638ms
isEvenModulo completed in 7.365179ms
isEvenAnd completed in 9.679149ms

In most cases this new & logic was actually a touch slower, almost always within the variance between runs, but the more salient point is that both implementations are far faster than you'll likely ever need, and will both be dwarfed in runtime by any other significant process - an obvious example is the garbage collector.

If you find yourself needing this kind of optimisation (you won't) then you're already using the wrong language.

sorry, but this is premature optimization (https://effectiviology.com/premature-optimization)
it's not as readable as the solution you had before and optimitations like this
should be justified not just by saying "it's faster" ... it's very likely
the classic number % 2 == 0 is not your problem if you have to do a performance optimization.