Why are angles usually represented by floats in programming?
Because floats are the best we have for this, out of the box.
My idea is that, if an unsigned 32-bit integer is used for representing angles in a way that 0 is 0°, 231 is 180° and 232−1 is just under 360°, all possible values are used and evenly distributed among all angles. Rising large values would naturally overflow to 0, which corresponds to the equivalence of 360° and 0°. (Edit: 216 → 231; it's supposed to be a half of 232.)
What you're doing is called fixed point arithmetic. You've simply chosen a scaling factor of 2π/232. It works. But using it is, well, work. It's not supported directly by typical hardware, languages, or libraries. Least none that I know. This means to use it with any of those you're going to be converting it. And once you convert it you lose much of what you were hoping to gain from it. Which frankly is only a few mantissa bits. If you want to work with it natively you'll have to stick with a subset of operations that still work natively.
What you lose is the ability to float your precision. Which might not be important to your applications but might be for the apps of others. This is why floating point won over fixed. Even when the number range only goes from 0-2π using floating point lets you express two numbers closer together then fixed point can with the same number of bits. And that might be useful even if you know that the number is expressing an angle.
Most language libraries and game engines that I used have goniometric functions for angles in radians as floats. If a 32-bit floating-point number is used for representing angles, not all of its range is used, and values just under 360° are less precise than values just over 0°. If an angle is increased beyond 360°, it needs to be explicitly wrapped below 360°.
That depends on the library. Some are happy to calculate sin(720°). If not, modular division lets you do it yourself.
Knowing that the number is an angle doesn't really help as much as you might think. You're just wrapping the number line around a circle. There are an infinite number of numbers between 0 and 2π, circle or no circle. You're not going to be able to express them all.
Fixed point's biggest advantage is that it's conceptually simple. Take every expressible number and place them evenly spaced over your number line.
Floating point doesn't insist on even spacing. By doing that it can put some expressible numbers closer together. The closer the numbers are to zero the closer together they are. Why? For the same reason you care about miles when planning a trip from city to city but not inches. But do care about inches when trying on shoes. At different scales, significance shifts. A floating point scheme takes that into account.
To visualize the difference here's a sketch. It starts out showing a fixed point scheme. Each expressible number (the dots) is evenly spaced. To move to a floating point scheme, the next line takes out every other dot and moves them close to zero. Same number of dots (because we're using the same number of bits) but now we have some numbers closer together. The third line simply continues the pattern.
0 . . . . . . . . . . . . . . . 1 Fixed
0.......... . . . . . . 1
0____...... . . . 1 Float
That seems weird because it is weird. But it lets us express very small numbers with very few bits without breaking the math that lets us work with them. Now sure, it also lets us express very large numbers that, for this, you don't care about. But it wasn't designed just for you.
Fixed point is conceptually simpler but less flexible. If someone told you computers can't do fractions in anything but floats they lied. But for computers designed to support fractions natively IEEE floats are the most popular, for good reason.