So it was my intention NOT to use any non-integer calls ;)

Unlike Array.Sort, this version doesn't change the array that it is passed.
We could change the int[] to IEnumerable<int> without any other changes and this would continue to support arrays while allowing other collection types and queries to be passed to it -- Array.Sort works only on Arrays.
This version is written as an expression-bodied member, the Array.Sort version cannot be written as an expression-bodied member -- it requires a code-block for the method body and a return statement.

Yes, Array.Sort performs better, but this version performed well enough to pass the tests and has all the above benefits. I'll offer that best-practice is at somewhat subjective, but there are tangible reasons to appreciate this implementation.

I don't know why this is voted as Best Practice. If you just call Array.Sort and return the element at index pos-1, benchmarking shows it will run over 10 times faster, without any allocations or garbage generation, and will be just as readable.

It seems that nowadays new programmers almost forgot that performance is a valuable feature of every code.

I like how you incremented 'rot' when iterating the rotors instead of additionally iterating the remaining characters for every rotor like I did.

Only thing I don't like about it is that you concatenate the result strings in every rotor iteration. Would have been more performant to allocate char arrays and replace the elements then create a string from it when it's finished.

Seems like people are so obsessed with making a one-line solution that they have no regard for sensibility or performance.

I couldn't tell if you were being sarcastic at first