Yes it's a good decision, and 'the standard' for audio in the same way as 32-bit ARGB makes everything easier for graphics. Of course there are some things that are better done with ints or maybe doubles, like keeping track of the time position, but for the sine wave generator it doesn't need to know how long it's been running in total, just the position in the current cycle, so floats are fine for that.

The alternative that my older code used was int16, and it has way bigger precision issues (32-bit float has 23 bits of precision, and in16 has 15). Fundamentally audio samples are just numbers; the fact that they have to be in the [-1..1] range in the end is a hardware technical limitation (the speakers' membranes can only vibrate so much), but there's nothing in the audio itself that says it should be constrained to some range. So, floating-points are a nice fit. Fixed-point math like 16.16 might be a good alternative, but floats have hardware support, so here we go.

The smallest nitpick: The accepted variable for frequency is f or nu (ν). The formula and units are correct in the article, but lowercase omega is understood as angular frequency and would take the place of 2πf. I also got 3 hours of sleep, so I could be wrong.

Also, thanks for the great article and a possible alternative to my own SDL_mixer woes!

One big reason is that when you add two samples together, if you overflow a signed int that's UB, but if you go over 1.0 on a float it's just business as usual. This means you can do a ton of audio processing and only have to deal with fixing the overflows in one place right at the end (they use a compressor, but other algorithms are also possible).

Freedom from overflow, and noise floor stays level-dependent. Meaning that when you multiply your float signal by a certain volume the quantization noise is at most -140 dB RMS. If it were integer, the quantization noise would depend upon how oud your (signal x gain) is. Besides, top-level compressor/reverbs use double :)