"Not necessarily".

Of course there are situations when these two methods of DOM update are on par.

But in any case I agree with one of answers there:

"If you don't mind the fact that innerHTML is a bit limiting (only total replacement of DOM sub-tree rooted at target element) and you don't risk a vulnerability through injecting user-supplied content, use that. Otherwise, go with DOM."

When you do for example this: element.setAttribute("a","b"); browser

1. drops all resolved CSS rules on element, its siblings, its parent and all children. Just in case you have CSS rules like:

  element[a="b"] > span { display:none }

2 Invalidates rendering tree of the element's parent.

And when you do element.appendNode(node):

it does the same as above + plus ensures consistency of HTML DOM (<select> cannot contain <div>s for example).

If you have multiple calls like these then all steps above need to be done for each of them. Engines can optimize such cases but not that much in some cases.

While browser do element.innerHtml it does each step strictly once: build consistent DOM, resolve styles, build rendering tree and mark window [area] as needed painting - request painting.