The technical cause is most likely due to write-caching - this being a feature of high volume HDD and SSD storage devices.
For most desktop computers, it is possible to configure an externally attached storage device either for performance (i.e., uses write-caching) or for Quick Removal. This determines how and when information is “written” to the storage device.
When configured for Quick Removal, information from the host computer is written immediately to the storage medium. This has the advantage that you may disconnect the storage device from the host computer, without risk of corrupting the file-system, at any time that data is not being actively transmitted to the storage device. Whilst being a completely valid and useful method of managing data storage, for reasons beyond the immediate scope of this description, this method is less efficient and slower.
Alternatively, when write-caching is enabled, information from the host computer is “cached” in separate (high performance) volatile storage within the storage device - and when sufficient information has been received, a “block” of data is written in a single write-cycle. Whilst being faster and more efficient, this method comes with the penalty of the host computer having to notify the storage device of a impending device-disconnection before it is disconnected. This warning ensures that the storage device will flush any pending data from its volatile cache-memory to non-volatile storage - and in so doing sets a “clean switch” on the flash filesystem and signals to the computer that it is safe to disconnect.
A drive configured for write-caching, upon connection to a host computer, is checked for the “clean switch”; if present, the storage device is “mounted” and made available to the operating system. By contrast, if the “clean switch” is not detected (this will occur if the storage device was disconnected prior to being notified of a “dismount”), the filesystem must be assumed to be potentially corrupt; pending data within the write-cache may not have been written to the drive.
So, the relevance of this to iPad is simple; iPad does not fully support devices that are implement write-caching. iPadOS lacks the ability to inform the storage device of imminent disconnection of the storage device from the USB bus. iPad also lacks capability to detect and scan/repair corrupt storage devices.
In summary, now that you [hopefully] understand both the cause and effect, you will now understand that you can only reliably use USB-connected storage devices that can be configured for Quick Disconnect operation - this having major significance to non-corruption of the filesystem and reduced data throughput.
Unfortunately, with iPadOS lacking a native mechanism to reliably dismount a running filesystem, the only available mechanism to safely dismount is to shut-down the iPad before physically disconnecting:
Settings > General > Shut Down
I hope this technical explanation is helpful in fully explaining the behaviour that you observe.
