That's a mistake no mater what application you're importing to, else we'll be graced with another blog post, "Darktable app Corrupts Photos".
What's the purpose of RAW+jpg though? Seems rather redundant?
Processing RAW can be expensive time wise. If you’re sorting through a session of 10,000 photos, you want the speed that comes with the jpeg variant, which allows you to quickly sort out blurry, smeared, severely mis-exposed, and other various defect photos.
The storage cost is negligible (JPEG75@10MP is cheap) and the workflow benefit is immediate. Additionally, cropping and early white balance corrections (as well as a handful of other things) are much faster to preview with a non-RAW version of the image; since you’ll be processing that detail later anyway from scratch in the RAW later, it’s functionally free to do it on the jpeg version before you dig into the raw.
Additionally, there’s a cheap debugging aspect that you saw here: was it Apple Photos mishandling ORF? Was it something else? When working with both, you have a “reference” that can be used to make sure your digital development pipeline is set up correctly; finer details about the imager can sometimes get mangled by some RAW developers like pixel order and sub pixel blending. Not every CCD is a linear grid, not every LCD looks the same, but if you can get your RAW pipeline producing ≈the same as your camera did, it verifies that you have things mostly set up correctly.
GP isn't wrong though. Most cameras embed a medium quality full-resolution JPEG along a couple different thumbnails in raw files, so saving raw+normal JPG is kinda pointless, because the raw already contains that jpeg. Raw+jpg is only easier in the sense that many/most non-vendor tools - even viewers - can't properly handle the embedded jpg so it's easier to just duplicate the storage (e.g. 50 MB for the raw + 10-20 MB for the JPG) and take the hit on storage consumption/transfer time.