“Java方式”本质上是混乱的。
我说这是一个好的做法，但我没有遵循。
测试通常能确保我做了我想做的事情，而且对我的审美来说太混乱了。

一些项目经常将final应用于所有的 * 有效final* 局部变量。我个人发现阅读这样的代码要容易得多，因为认知负荷减少了。一个非final变量可以被重新分配到任何地方，在具有多层嵌套if和for的代码中尤其成问题。你永远不知道什么代码路径可能已经重新分配了它。
至于代码混乱的问题，当应用于局部变量时，我并不觉得它有什么危害-事实上，由于语法着色，它使我更容易识别所有声明。
不幸的是，当final用于参数、catch块、增强型for循环和所有其他地方时，除了狭义上的局部变量，代码确实会变得混乱。这是非常不幸的，因为在这些情况下重新赋值会更加混乱，而且它们在默认情况下应该是final的。
有一些代码微调工具可以标记这些变量的重新分配，这很有帮助。

我认为这是一个很好的实践，对于维护程序员（包括我！）来说比对于编译器来说更好。如果我不需要担心方法中的哪些变量可能会改变，那么考虑方法会更容易。

是的，这是一个非常好的想法，因为它清楚地显示了在对象构造时必须提供哪些字段。
我强烈反对它造成“代码混乱”的说法;这是语言的一个好的和强大的方面。
作为一个设计原则，如果可以的话，你应该让你的类成为immutable（所有final字段），因为它们可以被安全地发布（即自由地传递而不用担心它们会被破坏），尽管注意字段本身也需要是不可变的对象。

它绝对会给你一个更好的代码，很容易看到哪些所有的变量都要改变。
它还通知编译器它不会更改，这可以导致更好的优化。
沿着，它还允许您的IDE在您可能出错时向您发出编译时通知。

一些好的分析工具，如PMD，建议除非必要，否则始终使用final。
但我认为代码中有这么多的最终标记可能会使它不太人性化。

我会说是的，与其说是为了编译器优化，不如说是为了可读性。
但我个人并不使用它，Java本身就很冗长，如果我们遵循所有被认为是“好的实践”的东西，那么代码将无法从所有样板文件中删除，尽管这是一个偏好问题。

你差不多总结了利弊...
我可以再加一个骗局：
代码的读者根本不需要推理最终变量的值（除了罕见的坏代码情况）。
所以，是的，这是一个很好的练习。
在你习惯了之后，混乱也不是那么糟糕（比如unix：-P）。另外，典型的IDE会自动为你做这件事...