Unsigned 16 bit int values will range from 0 to 65535. Typical 16 bit RAW cameras will store pixel voltage as 16 bits values, thus Yielding 65536 levels of the dynamic range. That's your question answered: an int can store a big value, if you give it a large quantification
Since as soon as you apply a gamma correction to the signal, there is literately no real use to keep that much quantification. Most codecs will try and fit actual display capabilities, ranging from 8 bits for standard displays up to 12 bits for rare very high quality professional displays.
My understanding of why Resolve uses floats instead of int goes as follow:
Resolve has a really special use for those numbers, it's going to mess arround with them a lot. Internally it's working with signed 32 bit float numbers, each pixel value can range from -3.4^38 to + 3.4^38. No matter what number was stored by the camera, it will (very) comfortably fit in the range. Please note the appearance of negative values, this is a very interesting feature. It is useless to have negative numbers in cameras or delivery codecs, since pure black is coded by zero, and nothing is darker than pure black. Resolve will however use those numbers in calculations to avoid rounding errors (clippings) building up. It of course has the side effect to allow you to have a grade crunch or burn the picture in one node and then retrieve those pixels in an other node down the line.
At the output level however, if a pixel is coded by a value outside the range of the display it will clip. Delivery codecs such as Apple ProRes will actually not even implement signed values, all that they can store are positive integers (ranging from 0 to max quantification)
Caching within resolve is where it gets tricky. If you pick an delivery codec (any standard codec really) you will clip any numbers falling out of the display range in your cache. So for a 10 bit codec, any numbers bellow 0 and above 1023 will get clipped. Caching RAW has this drawback that not only your cached node can't have anything darker than black retrieved later, but more noticeably is that any number above 1023 is also clipped, and that is what most people will see since the RAW footage didn't feature any negative value pixel to start with.
Resolve has addressed the problem by allowing us to store float numbers in the cache. The first "codec" available for that was the 16bit float RGB. They picked 16 bit since 32 bit was a bit of an overkill and twice the size in storage space: the maximum value a camera rush can hand to resolve is 65535, and the max 32 bit float is tens of orders of magnitude bigger than that (3.4^38). They could have picked 16 bit int, since it would match the rushes, but then no negative numbers would be cachable. They could also have picked signed int, but the range then falls down to –32,768 to 32,767 and would introduce clipping once again so they picked float instead.
It turns out,
the range of a half float (16 bit float) is -65504 to 65504, at the loss of some precision in the large numbers but much increased precision in the small ones, which is really where we need the most of it (the 0-1024 range).
I've found out that all labeled HDR cache codecs (444s essentially) store their values as 16 bits. So they are clearly not vanilla implementations of those codecs. I've actually tried many methods to read them independently (VLC/FFMPEG etc.) without success. I do not know however if those 16 bits are float or int, I yet have to come up with an idea to test that. However either way, I would concur with the fact that there is no real reason to cache in 16bit RGB float anymore. Even if it is integers that are stored in ProRes/DNxHR 444, with 32000+ levels of quantification I'm absolutely sure that it won't damage the footage in any noticeable way, especially if all you do is temporary caching to increase read performance!