No, loops are not bad programming practice.

They have a big advantage. You know what the processor is busy doing.

The bad thing? You know where the processor is stuck, i.e. you also know what the processor is not doing.

The advantage with a state machine is that the main loop can constantly check a number of state machines.

for (;;) {
    check_keyboard();
    update_diodes();
    handle_uart0();
    handle_uart1();
    check_battery_level();
    ...
}

If you don't use state machines (called from main loop or handled by ISR) for the keyboard, but have a for loop waiting for a key to be pressed, you will not be able to blink any LEDs while waiting. Or check if you have received a command on an UART. Or react to a quickly dropping supply voltage, possibly saving some state info into EEPROM memory while there is still enough power to safely perform the writes.

Embedded systems normally needs to do multiple things semi-concurrently. State machines are basically for loops that between each test saves their state and allows you to do an iteration for another loop somewhere before later restoring the state and perform the next iteration.

Another thing is that state machines need only save important state. Many temp variables need not be saved. If using an RTOS, then every task needs to be able to store not only the important state, but the individual tasks also needs space for all the temporary variables that are used by the task. This is irrelevant for a PC with GB of RAM. for an embedded chip with 1kB of RAM, you don't want to waste most of this RAM on multiple stacks and end up with hardly RAM for your critical variables.