I'm not 100% sure about the full reasoning behind Spine's color representation convention.
The colors are stored in the JSON in hexadecimal form (white is 0xffffffff), which would serve the 0-255 or 4-byte format.
DirectX uses the 4 byte representation too. OpenGL actually uses a bunch of formats but using 0.0-1.0 is pretty common.
Uncompressed image data is stored in the GPU in the 4-byte format. But as far as I know, the GPU actually commonly performs color calculations in 0.0-1.0 space. Or at least that's how it's programmed in shader languages. So it's kinda weird.
But related to that, to manipulate image colors before sending the data off to be drawn (in this case, combining the skeleton color with the colors of the individual slots), Spine actually makes use of a multiply formula, which only works when you have the 0-1 float representation.
This means black (0,0,0,1) makes the image totally black, and white (1,1,1,1) makes the image look normal, since multiplying anything by 1 doesn't change that number. Any color in between white and black then will make your image turn a darker tint of the original image.
Since it's using a multiplication formula, it works exactly like a solid multiply layer in Photoshop.
This also works well for how the alpha works. 50% is literally 0.5f. And 50% of 50% is literally 0.5f * 0.5f.
Sadly, this also means, out of the box, you can't brighten your images through this mechanism.
More to the point: being used to the 0-255 representation may have less to do with what's ideal. In Spine's case, 0.0-1.0 is just how it works because it needs to multiply quickly.
I guess this should be explicitly described in the documentation or some FAQ. It's a pretty easy mistake to make, especially for people who aren't familiar with color formats.
