最大的好处是内容（html）和动作/行为（javascript）的分离，这就是Unobtrusive javascript，保持它们的分离使得改变其中一个更容易，而不会影响另一个。

是的，至少在社区的某些部分，不确定你将如何衡量它的整体。
有 * 绝对 * 的优势，从我的头上：

• 更清晰/更少代码
• 更易于调试
• 更易于更改
• 更易于 Package
• 业绩

从数量上看，可以这样想：

<a onclick="someFunction();">
<a onclick="someFunction();">
<a onclick="someFunction();">
<a onclick="someFunction();">
<a onclick="someFunction();">

或者这个曾经：

$("a").click(someFunction);

你可以通过css选择器等在大多数框架中实现这一点，同时处理许多元素。这意味着在服务器代码中你只需要分配ID和类，客户端更容易单独处理。调试也更容易，例如：在控制台中，我可以执行$('a').unbind('click').click(...something new...);
另一个好处是性能.如果我能把它拆分成一个单独的.js文件，由客户端缓存，那么我就不会每次都发送更薄的网页和额外的数据.更小的网页=更快的加载.
这里还有一个例子，想想它有多简单，通过jQuery执行一些框架操作，但是内联事件看起来怎么样？

$("li").hover(function() {
  $(this).children().slideToggle();
});

相比之下，这是一个 * 巨大 * 的内联代码量，即使你忽略了动画部分，它也是混乱的（想想mouseenter/mouseleave，而不是mouseover/mouseout...前者，.hover()使用的，更复杂）

是否真的改变了内联声明事件的旧方法
是的，当然，特别是随着jQuery、Prototype等JS框架的兴起，所有这些都鼓励以“新学校”的方式声明事件。
如果是这样，其中一个的好处是什么？
主要原因之一是HTML结构和JavaScript编程智能之间的分离（可以说 * 确实 * 属于分离的）。它使标记更加干净，更容易维护，同时所有的编程逻辑都保存在单独的文件中，这具有加载性能的优势以及更好的可维护性-您有适当的库来包含代码，而不是到处都是JS代码片段。

使用内联声明，你只能分配一个事件处理器，而从代码中，你可以分配你想要的多个事件处理器。同样，如果你需要分配同一个事件处理器给多个元素，用javascript做会更容易，更短，而且你遵守DRY原则。