If your system can deserialize the data on the other end regardless of the field order, you don't need to enforce that order. But you probably want to anyway, because it's better.
If you have any dependency on that ordering (as in, you enumerate the results of
getFields() on the receiving end and deserialize each field in succession), you had best make sure you have control over it, or you will end up tracking down a very subtle-looking bug a long way in the future. Then you'll really kick yourself. This is the most important reason to order the fields, but it will also be useful for a programmer to know the expected ordering when he or she works on the system, or its data.
There are a few downsides to some ordering methods. They have the potential to introduce diffs within the middle of the serialized data, which can make versioning a chore (append-only versioning is much easier to deal with). If you can guarantee that you won't interoperate data between versions, this is less of a concern.
It's usually hard to get reflection APIs to return results in code-declaration order. So any ordering method (alphabetical, size, name hash, whatever) will have some disconnect with the layout of the structure as read by a programmer. At least with a defined, enforced ordering you know what that disconnect will be. The ordering of
getFields shouldn't be relied on and could potentially change underneath you when you least expect it.