Raw data has interspaced RG/GB pixel elements. To "pixel bin" is to combine neighboring pixel sensors. But you can't do that if your neighboring sensor pixel elements are of different color and you want the output to be in a "raw" pattern of RG/GB nature. So you should ignore the simple term "pixel binning" if you want to output raw data.
If you look at the CR3 algorithm, you can see that they look at each color's pixel elements separately and then convert pixel pairs to pixel averages and differences in a horizontal and vertical pass (I'd call an "image pass"), and repeat this image pass 3 times. You could strip out just the first averaged quadrant of the first image pass to have "1/4" size indeed, or you could strip out the averaged quadrant of the 2nd pass for "1/16th", or the averaged quadrant of the 3rd pass for "1/64th size. But this is still reading the entire sensor, doing CR3 compression and outputting a different slice of it and throwing away all the remaining data.
If you really wanted to do just that (and throw away all the other data which is really important), there are other "wavelet" compression schemes that would give you a better reduced-size image quality of averaged pixel elements than that. I say this because I have used one of them in the past, and it was designed to use a single horizontal and a single vertical pass to combine a much longer set (than just 2) of neighboring similar pixel elements together with appropriate weighting to yield a single pixel to get a result in one "image pass".
The problem with both of these techniques is that while the reduced averaged data has been done for R, G, and B separately, it is now WITHOUT the "raw" nature of having them still in a RB/GB nature. Now they're in an overlaid RGB nature together per pixel, which is akin to de-Bayer'ing and size reducing the image. If that's all you want, then you're just competing with jpg or heif for a reduced size non-raw output.
If I was in charge at Canon, for "raw output" I'd use quadrature encoding & run length output (what CR3 basically is) but keep it lossless and tell the user what that output size is as a percent of the original. Then if they want the size reduced further I'd use different amounts of "low bit" discarding of the various quadrant sections (as intelligently needed per quadrant area) so that they have a smaller data size file (possibly a VERY small file) but still a RG/GB nature raw file of the original image size. To be clear, this very small encoded file would still be decoded (quickly) into a full size raw version so it'd work with PhotoLab, etc. You could make it easier on the user by asking them what maximum % of original file size they want the raw output to be and then they'd get the best image quality possible in a raw encoded format for full-size image output for the reduced file size wanted by the user.