for instance, i have a pool with plenty of datasets that have dedupe off and only a crucial few with it enabled: the ones that are nfs-mounted media storage volumes for fediverse instance containers that would otherwise all duplicate all media they see in common, which is most media posted to any of them and a good bit of the remote media received by any of them. the size of the dedupe tables in memory is purely a function of the number of blocks written to those few datasets and i expect to either sunset this laptop from 2012 or migrate the pool to a fresh one long before i would be worried about the memory cost of deduplication swelling a few orders of magnitude to where i'd have to care.

...per unique TB written to datasets with deduplication enabled, of course, not the pool as a whole (even though that ram cost is indeed at the pool level).

there are plenty of useful things to be done with zfs dedupe at practically no cost if you design for it ahead of time. unfortunately for some reason people parachute into every thread where zfs comes up to say you can never ever turn it on, so people are taught not to even try.

how exactly do you propose someone looking to delete all of their old posts from a dead instance might obtain the exhaustive list of instances that have historically received their posts via a long indirect cascade of boosts to send these formal or informal deletion requests? an allowlist-federated instance obviously makes that far more tractable, and otherwise I could potentially see annoying paths to doing it anyway if i had been the admin and had every log ever sitting somewhere to trawl through, but in the case of a normal user whose instance is already gone and who doesn't have an ongoing relationship with the prior admin, this is hardly a realistic way to address that concern.