I’d imagine the main drawback of using H.264 here is that you’d still have to decode to get the frames back. This is similar to how even though many consumer grade cameras will output natively to h.264, if you want to edit the videos from it you’d usually have to convert it to prores or something first (the editor would usually do this automatically behind the scenes)
I’m not sure if lossless h.264 is I only or not, but if it uses inter-frame compression then it’s difficult to randomly access arbitrary frames. For any arbitrary frame you’d have to find the nearest key frame, then interpolate from there based on the inter-frame compression metadata.
It's acceptable to use the nearest key frame when randomly accessing arbitrary frames.
The real problem is that you'd have to rewrite the entire app stack to use H.264 or AV1 for storing the image stack generated by CT.
CT images are 16-bit monochrome, and the pixel values have real physical meaning (Hounsfield Units). So you'd have to prove that your compression tool can reproduce the original images 1:1. The H.264 encoder would also need to be modified to support 16-bit pixels.
And you'd need to modify the post-processing tools to accept your new file format. Otherwise users will still have to convert it back to DICOM or some other commonly accepted format before they can use their post-processing software.
So unless you're a CT vendor, you'll have a hard time pushing this into a hospital.