Aaaaah... WriteByte() abuse.
Short version: It's doing a certerprint 2 characters at a time.
Long version: Somewhere preceeding that, is a line that probably says WriteByte(MSG_ALL, SVC_CENTERPRINT); This tells it that there is a centerprint being sent to all clients.
Technical note: The centerprint() builtin only sends to one client usually, so it's already doing for centerprint() what bprint() is for sprint()
When doing this, there are things to note. Firstly, the centerprint message will only end with a null byte (sometimes referred to as \0), so that will have to be sent at some point. Secondly, WriteString() will send any string followed by a null (for reasons I won't go into, strings have to have a null at the end). This means that if you need to send multiple strings, you can only use WriteString() for the last one.
This isn't an issue with centerprint(), because you can use upto 7 strings with the builtin, either by creating multiple definitions each with a different number pf strings, or by using the varargs feature of FrikQCC or FTEQCC. But as mentioned perviously, there are other reasons why we can't use the builtin.
The main reason for needing WriteByte() abuse, though, is that because strings are actually handled as pointers, and you generally only get one temporary string, you can't print two numbers in the same centerprint. There are workarounds to this issue that are easier to use, but they involve changes to the engine code, which is not easily possible to guarantee.
Which brings us to the part that you quoted. WriteShort() is being used instead of WriteByte() to send two characters at a time, for a slight increase in speed, at a cost of readability. Converting 62959 to hexadecimal gives F5EF, which gives u and o. For reasons that I won't go to, large numbers are sent "big endian", meaning that this is sent as ou.
That's the basic idea of what it's doing.