¿Qué hace Y 0xFF?

Si byte1 es un tipo entero de 8 bits, entonces no tiene sentido: si es más de 8 bits, esencialmente le dará los últimos 8 bits del valor:

    0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1
 &  0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1
    -------------------------------
    0 0 0 0 0 0 0 0 0 1 0 1 0 1 0 1

El peligro de la segunda expresión viene si el tipo de byte1 es char. En ese caso, algunas implementaciones pueden tenerlo signed char, lo que resultará en una extensión de signo al evaluar.

signed char byte1 = 0x80;
signed char byte2 = 0x10;

unsigned short value1 = ((byte2 << 8) | (byte1 & 0xFF));
unsigned short value2 = ((byte2 << 8) | byte1);

printf("value1=%hu %hx\n", value1, value1);
printf("value2=%hu %hx\n", value2, value2);

Se imprimirá

value1=4224 1080     right
value2=65408 ff80    wrong!!

Lo probé en gcc v3.4.6 en Solaris SPARC 64 bit y el resultado es el mismo con byte1 y byte2 declarado como char.

TL; DR

El enmascaramiento es para evitar la extensión de signo implícita.

EDIT : He comprobado, es el mismo comportamiento en C++.

Asumiendo que su byte1 es un byte(8bits), Cuando se hace un bit a bit Y de un byte con 0xFF, se obtiene el mismo byte.

Así que byte1 es lo mismo que byte1 & 0xFF

Decir byte1 es 01001101 , entonces byte1 & 0xFF = 01001101 & 11111111 = 01001101 = byte1

Si el byte 1 es de algún otro tipo, digamos un entero de 4 bytes, a bit Y con 0xFF te deja con el byte menos significativo(8 bits) del byte 1.

El byte1 & 0xff asegura que solo los 8 bits menos significativos de byte1 pueden ser distintos de cero.

Si byte1 ya es un tipo sin signo que tiene solo 8 bits (por ejemplo, char en algunos casos, o unsigned char en la mayoría) no hará ninguna diferencia/es completamente innecesario.

Si byte1 es un tipo que está firmado o tiene más de 8 bits (p. ej., short, int, long), y cualquiera de los bits excepto el 8 menos significativo se establece, entonces habrá una diferencia (es decir, cero los bits superiores antes oring con la otra variable, por lo que este operando de la or afecta solo los 8 bits menos significativos del resultado).

Borra todos los bits que no están en el primer byte

& 0xFF por sí solo asegura que si los bytes son más largos que 8 bits (permitidos por el estándar de lenguaje), el resto se ignoran.

Y eso parece funcionar bien también?

Si el resultado termina siendo mayor que SHRT_MAX, se obtiene un comportamiento indefinido. En ese sentido, ambos funcionarán igualmente mal.