在我看来，混淆似乎是一种落入“安全性靠模糊”或“虚假保护感”阵营的想法。为了保护知识产权，有版权；为了防止发现安全问题，有“修复这些问题”。简而言之，我认为这是对社会问题的技术解决方案。这几乎从来不奏效。
然而，我似乎是我们开发团队中唯一持此观点的人，所以我可能是错的，或者只需要有说服力的论据。我们的产品使用.NET，一个开发人员建议使用.NET Reactor（顺便说一下，这个SO线程也建议了它）。
.NET Reactor通过将任何纯.NET程序集（用C#、VB.NET、Delphi.NET、J#、MSIL编写）与本机机器代码混合，完全阻止了任何反编译。
所以，基本上你一下子就放弃了字节码的所有优势？
混淆有好的工程化益处吗？
您要求的是工程方面的原因，因此严格来说这不是对问题的答案。但我认为这是一个有效的澄清。
正如您所说，混淆旨在解决社会问题。而社会（或业务）问题与技术问题不同，很少有完整的解决方案。只有通过解决或最小化问题来取得一定程度的成功。
在这种情况下，混淆会提高某人反编译和窃取代码的门槛。它会阻止偶然攻击，并通过惯性使您的知识产权更不可能被盗用。打个烦人的比喻，汽车电子防盗系统不能防止您的汽车被盗，但它确实会降低被盗的可能性。
当然，这样做有成本，在可维护性、（可能的）性能以及最重要的是使用户难以提交准确的错误报告方面。
就像GateKiller所说，混淆不会阻止决心坚定的团队进行反编译，但取决于您的产品，攻击者团队有多么决心攻击您？
因此，这不是针对社会问题的技术解决方案，而是一种技术决策，它为复杂的社会结构增加了一个影响力。
在某些情况下，混淆可以带来一些工程上的好处，例如混淆JavaScript代码可以得到更小的文件（因为所有变量都被命名为“a”和“b”，而不是“descriptiveNameOne”，并且所有空格都被删除等）。这会使使用混淆JavaScript的网页加载速度更快。显然，在.NET世界中这种好处不太明显，但它是一个直接体现工程价值的例子。
虽然与.net无关，但我认为JavaScript和其他解释语言可能需要进行混淆。JavaScript受益于混淆，因为它可以减少所需的带宽和解析器必须读取的标记。
但是，对编译后的字节码进行混淆似乎并不那么有用。我的意思是，你想要达到什么目的呢？我只能看到混淆在许可证检查代码中略微有用，以避免它被过于轻易地规避。
使用加密来保护信息在传输过程中的安全。
使用混淆来保护程序持有的信息的安全。
