I believe there is a fundamental misunderstanding here. The original FIX Specification including the excerpts from Volume 1 were written with a tag=value encoding in mind. Meanwhile, there are many additional encodings available, i.e. FIXML, FAST, SBE, GPB, ASN.1, JSON. I admit that FIX has a to-do here to separate the application layer more clearly from the encodings (presentation layer) in its documentation.
So why is the order of fields in a repeating group relevant for tag=value encoding? There is no explicit delimiter of repeating group instances and no explicit end either. Hence the occurrence of the first field as defined in http://fiximate.fixtrading.org/latestEP/ serves as the instance delimiter. The sequential parser finds it and can safely assume the beginning of a new instance. The ending of the entire group is implicit as well. As soon as the parser finds a field that does not belong inside the group it assumes the repeating group to have ended.
However, all encodings except tag=value have delimiters for repeating groups and their instances, either explicit in form of brackets or implicit in form of schema information (e.g. byte length). The ordering of fields can therefore be changed and it may make sense to support byte alignment for performance reasons. Market data with FAST is one of those use cases where it makes sense. I would suggest to maintain the ordering found in FIXimate whenever performance does not play a role, e.g. with FIXML. It simply makes it easier to understand a given FIX interface. The FIX Global Technical Committee bases ordering on semantical relationships between fields. New fields are entered with this objective in mind.
To be clear, encodings other than tag=value may also not place fields outside of a repeating group as this changes the semantics of the message. But they can choose and order of the fields and nested repeating groups inside (with the caveats from above).
Last not least a comment for @aybiss: agree that FAST is quite complex and can be challenging even though it is a great encoding when bandwidth is the issue (it was at the time). Suggest to take a good look at FIX Simple Binary Encoding (https://www.fixtrading.org/standards/sbe/), a fixed length binary encoding that has removed many of the complexities of FAST and is intended for high performance interfaces (transactions or market data). It is “simply the best” as Tina Turner would put it