The spec uses this as an example: (Part 6 section 5.2.6)

=====================
struct Type1 {
Int32 X;
Byte NoOfY;
Type2* Y;
Int32 Z;
};

In the C/C++ example above, the Y field is a pointer to an array with a length stored in NoOfY. When encoding an array the length is part of the array encoding so the NoOfY field is not encoded. That said, encoders and decoders use NoOfY during encoding.

This is confusing.

In C/C++ the field NoOfY is a separate field that is unrelated to anything, which to me implies it ought to be encoded along with all other fields.
It is only because we "know" it contains the length of the array pointed to by Y that it should not be encoded - but there is nothing in the struct that makes that clear. Y could point anywhere, making its relationship to NoOfY less clear.
The table below the example shows Y.Length is 4 bytes (Int32) and not a byte containing the length - this is also confusing and does not explain why it is ok to change the type from Byte to Int32

I think a better example would be
struct Type1 {
Int32 X;
Type2[] Y;
Int32 Z;
};

This shows a C/C++ struct that has an explicit array. Its length is made explicit in the encoding as Y.Length. It also implies that the bytes are contained inline in the struct, and not located in a memory location pointed to by Y.
If the goal is to show this in C using pointers, then this would be less confusing

struct Type1 {
Int32 X;
Type2* Y;
Int32 Z;
};

with a note that explains that the length of Y must be made known to the encoder through some other mechanism.

It could also use this (similar to original)

struct Type1 {
Int32 X;
Int32 LengthofY;
Type2* Y;
Int32 Z;
};

with a note that explains that the two fields "LengthOfY" and "Y" combine the semantics of "[]Y". It a kind of RPC syntax, where the size of a field is contained in the value of a different field - in this case, the encoder "knows" it is the number of elements in Y