Atmel SPI "wait for transmission complete" example is wrong?
According to the same manual 18.5.2

When a serial transfer is complete, the SPIF Flag is set. /--/
the SPIF bit is cleared by first reading the SPI status register with SPIF set, then accessing the SPI data register (SPDR).

These kind of peculiar flag clear procedures, where you clear something by reading are somewhat common with SPI and UART. Their code example is correct, since it loops while the flag is not set, waiting for transmission to be complete.
However, if you were to peek at this code from a debugger, the debugger might also be displaying a memory map or reading the registers through its watch list, as if the registers were any local variable. And thereby destroying the flag. This is a well-known and very annoying phenomenon with debuggers. If you suspect this to be the case, then you could try to not break or single step through the function, but set a breakpoint directly after it and run til there.
Your examples will not hang because they are incorrect, they don't wait for the flag, they just check if it is 1 - it is not, then leave the loop.

General advise about bad practice to avoid:

Don't write icky macros to hide bitwise operators. C programmers know what SPSR &amp; (1 &lt;&lt; 7) means. They do not know what BIT_GET(SPSR, BIT(7)) means. The only thing you achieved with the macro was to turn the code far less readable.

Never bit shift the value 1. Integer constants have a type like variables and in case of 1 it is a signed type. So if you do 1 &lt;&lt; 15 on a 8 bitter AVR you actually have an undefined behavior bug, since you are shifting data into the sign bit of a signed int. To avoid bugs like that, always write 1u &lt;&lt; n so that the arithmetic is carried out on unsigned types. This is a common rookie mistake, one made by the person who wrote the Atmel datasheet among others.