If you are comparing Duplicacy against immutable snapshots, then you shouldn’t be pruning since there’s no equivalent to prune with immutable snapshots.
And how is “upload corrupted file version.” worse for Duplicacy than your other solution? With Duplicacy every block is named by it’s hash, extra files aren’t a problem (there’s no path to them). And if you are paranoid, do a check which can download and check hashes of all files.
All previous states are available if you never prune.
I think you are mixing things up. I am not comparing Duplicacy with anything - it actually does not matter what backup software is used, the issue is with storage behavior itself.
No matter what data you write to storage - as long as you can write (and in case of B2 - “soft-delete”), there is a way to corrupt written data. Once this is done, you have to restore to a point in time when storage state was valid - in case of the snapshot, you have it ready and available for you immediately.
In case of B2, data is there, but it is NOT directly accessible as is - the state of the storage needs to be reverted - for overwritten files “bad” version needs to be deleted so the previous, “good” version becomes visible and for “soft-deleted” files the “hide” marker needs to be removed.
So B2 can “emulate” storage snapshots - data is there, safe, but there is no real tool to do that, unfortunately 
This is all besides the issue with unattended pruning - where credentials with actual delete permission needs to be stored on the system…
If you want to compare Duplicacy with FS snapshots, you actually have to take into account data life cycle configuration - if you have immutable snapshots for the last 7 days, that only means that there is a “prune job” running somewhere cleaning older data 