Rust translation!

Still, one of sentences suggests the stronger requirement: "[...] find out whether the cuboid has equal sides (= is a cube)".

EDIT: okay I see you updated it.

It doesn't say if it is a cube it says if it could be:

Return true if the cuboid could have equal sides, return false otherwise.

And that has already been mentioned here: https://www.codewars.com/kata/58d248c7012397a81800005c/discuss#642de3f56555a387e8795e45

Anyways, I've changed the description to replace has and = for could have and could be.

And All stops after the first mismatch. Both perform the same here.

The point is that it's bad practice to mutate input. Undocumented side effects like that are hell on readability.

Using Linq is adhering to KISS. Yes Linq has performance issues (though often overstated and it does get better with each iteration of .Net) but in 99% of use cases Linq won't be your performance bottleneck and if it is then you can just not use it in those cases.

The advantage of Linq is easier to write/read code. It is far more concise without losing any readability (assuming everyone is passingly familiar with the syntax).