Public key derivation for Ed448
If you read all of the RF 8032 you will see that there is a compression (endcodings) of the points.
def point_compress(P):
    zinv = modp_inv(P[2])
    x = P[0] * zinv % p
    y = P[1] * zinv % p
    return int.to_bytes(y | ((x &amp; 1) &lt;&lt; 255), 32, &quot;little&quot;) 

Compression just stores the sign and restores it back with this information
def point_decompress(s):
    if len(s) != 32:
        raise Exception(&quot;Invalid input length for decompression&quot;)
    y = int.from_bytes(s, &quot;little&quot;)
    sign = y &gt;&gt; 255
    y &amp;= (1 &lt;&lt; 255) - 1

    x = recover_x(y, sign)
    if x is None:
        return None
    else:
        return (x, y, 1, x*y % p)

The above has been defined for Ed25519, there is no code for Ed448 in the RFCs as I can see. However NIST.FIPS.186-5-draft defined it for both;

For a curve point $(x,y)$ with coordinates in the range $0 \leq x, y &lt; p,$ first encode the $y$-coordinate as
a little-endian string of 32 octets for Ed25519 or 57 octets for Ed448. For Ed25519, the most significant bit of the final octet is always zero, while for Ed448, the final octet is always zero. To
form the encoding of the point, copy the least significant bit of the x-coordinate to the most significant bit of the final octet

As we can see, the LSB of the $x$-coordinate is placed in the MSB of the final octet (byte) of the $y$ coordinate. Therefore, the total size of the public-key is 57 bytes.
Although the compression has a time-consuming and little advantage on the storage/transmission it also helps in the point validation. The second and third options are verified during decompression.

The $x$ and $y$ coordinates of $P$, $x(P),y(P)$ are valid elements of the field.
$P$ satisfies the curve equation - against the twist attack.