This might be hardware / software specific.
You can reproduce this kind of artifact with a "simple window" that tries to map a narrow range of the original scale to a wider range. Each individual pixel is described by an integer, which, once it goes through the linear mapping transformation gets transposed to a different bin.
An extreme example would be trying to map the range 0..1 to the range 0..7 with both ranges originating from natural numbers. There is nothing else in the range 0..1 except 0 and 1. Consequently, there is nothing to map to 1,2,3,4,5,6. If you tried to map 0..3 to 0..99, you would again only fill 4 bins of the wide range.
You can "simulate" this condition over any image by trying a similar narrow->wide mapping:

What happens in your case is that the software (or your code) sees the full range as 16bit (65536 bins) but this 16bit range describes a much narrower 10bit (1024 values) range. What you see are the steps of this "re-quantisation".
The RGB image without any concern to the fact that there are three different histograms depicted does not show any overlap or interleaving. It is the same condition described above but the data from the three histograms do not have to "sit" exactly in the same values because they describe colours. If they did sit on exactly the same values, then the image would appear in grayscale (even if it had three channels).
If you don't like these bins, then simply re-map the values to a narrower range. There will not be any loss from this.
The point about this being hardware/software specific is that, depending on the application, the camera (or any libraries used by the camera or yourself) might be taking decisions that cannot be changed (e.g. re-map the 10bit values to 16bit values without being able to override or perform specific measurements and serve a ready made value). And in that case, more data would be needed to decide how to apply any further "correction" properly.
Hope this helps.