I think its a better deterrent to just release software updates often. Of course you need to give the user a compelling reason to want to update.
The task of maintaining on-going disassembly across multiple release versions of some software is actually straight forward. The "dumb" (but useful) way to do it is by finger-printing all of the subroutines in the old disassembly, and then using the fingerprints to identify the similar routines in the new disassembly (IDB2PAT). The "smart" way to do it is the graph theoretic approach of Halvar Flake.
Anyone in the Anti-Virus or compatibility industries can confirm both the capacity and the need to maintain disassemblies across multiple versions of software.
Pumping out a relentless stream of new versions of your software is no longer a deterrent, and hasn't been for over a decade.
When it comes to the efficiency of distribution, it's best to think of it in terms of the constraints and requirements.
Without a way to duplicate and distribute their products to customers, software companies could not exist, so the capacity to duplicate and the ability to distribute are both requirements.
Those very same duplication and distribution methods used by the company can also be used by others to further (re)distribute additional copies.
The difference is, the software companies are operating under the constraint of needing to make a living by selling copies of their products, so there's really no way to make a fair comparison on the efficiency of the methods used by the companies versus those people making additional copies. You're essentially comparing farmers to chefs; one produces food, while the other prepares the food.