dm-thin currently appears to be optimized for overwrite-in-place workloads, where allocation of new blocks is rarer. In some cases, many or even most writes require allocating new blocks. This is the case for very short-lived volumes that start out empty, such as volumes used to store container and/or VM images that are being built. It is also the case in virtualization systems that allow users to roll a VM back to the state before it was started, as this works by creating a snapshot when the VM starts.
It cannot be said 'dm-thin is not optimized' - it's the main design principle - which can be summarized with this simple logic: If you use 'thin volume' - and you takes it's snapshot - blocks are shared with other 'thin volume' from this moment (metadata operation). Now if you start to 'rewrite' blocks in such volume, since they are now shared, thin volume has to re-provision them - at this moment it does not matter which one from the 2 block 'holders' starts this first - but as long as the thin volume is not an exclusive block owner - the operation of re-provisioning happens. Note - the operation always happens with the context of running thin volume, so active operation on thin volume A does not influence anything on thin volume B,C,D... (except the lock contention with metadata work). As such it's not very clear how 'different' strategy of thin-provisioning should look like ? FYI some new patches for thin-pool which improves noticeably performance of thin volumes flows in - so worth to track newest kernels - some of changes might likely have positive influence on your observed problems. Generic advice: if there is not much 'sharing' in snapshots overall - increasing the block sizes may significantly reduce performance troubles with metadata handling.