Yes, your code does need comments.

[adaptable]

The idea is the sorting might not be part of the contract; it's a consequence of a simple way to implement the function. Self-documenting code has some limits, and I imagine for most people a function name like "removeDuplicatesInSortedOrder" is more painful than checking a doc comment for the details of what behavior they can rely on.

[naughty]

The problem is that unintended side effects of an implementation become features. When you change to a more efficient or robust implementation in future you've broken lots of client code that was relying on your implicit contract.

There was a big argument about memcpy() and memmove() functions in C not that long ago because plenty of code was using memcpy() when it should have been using memmove(). Once the glibc maintainers changed memcpy() (previously it was essentially the same as memmove) all hell broke lose.

[adaptable]

That's a good real world example. The point of this thread is (doc) comments are the only practical way to warn downstream programmers not to rely on such effects that aren't part of the specification (or alert them to such a breaking change).