this doesn't add extra security - the first hash becomes a substitute password. A cracker could modify their steam account to take said hash as input and sent it directly over the wire.

It doesn't remove any security, either. If you perform a hash on the server that sends an arbitrary input size to a fixed number of bits, the attacker needs only to try O(2^n) different inputs where n is the number of bits of that hash. By using a hash with at least n bits as a substitute password, there's no less security. It does mitigate the DoS vector, however.

no it doesn't remove any security, but why implement a feature that doesn't add anything?

It does add something: users can use any password they want. Any unicode string. You just UTF-8 encode then locally hash into a constant size. This alleviates the issue mentioned in the grandparent that supporting arbitrary length passwords introduces a DoS vector, especially when a slow hash is used on the server.

arbitrary length passwords simply aren't necessary though, and are unlikely to be used - if you were to cap passwords at, say, 128 characters, who would run into that limit?

I'm not arguing that if this functionality were already present in an app that you should remove it; however if it's not there already there's very little value it could add that would justify any development time. That's just my opinion though.