innerHTML has been slower than the DOM API for a few years. React had a big refactor at one point to rip out innerHTML logic precisely due to this. To make matters more interesting, the order of DOM API calls also mattered. In IE, building a DOM tree bottom up was significantly slower than building it top down (meaning, no large document fragments for you!). There are also a ton of other quirks: `.textContent = ''` being faster than removeChild, appendChild vs insertBefore vs replaceChild, childNodes random access, properties being faster than attributes (which is a rabbit hole of its own because SVG), cloneNode being faster but nigh unusable in a framework setting, orders of magnitude difference in performance due to data structure polymorphism...
Squeezing performance out of DOM manipulation is really tricky because the performance profile of pretty much everything changes frequently without rhyme or reason.
Not to travel too far off the main topic, but I use this exact fact to demonstrate to new developers why I prefer a developer that looks things up instead of relying on what "everyone knows". When Jeremy Keith's DOM Scripting book was written many years ago, it claimed that DOM methods were much slower than innerHtml. And that was true. If we all just took that as gospel, we'd be WAY off base.
So I'll take the dev that looks things up, as there's much more possibility they're operating on more up to date information.
Consequently, this is why I also tell people to stop repeating "this is a best practice" a year or so after something is discovered. It's a "common practice". You don't have enough info to know if it's truly "best".
Squeezing performance out of DOM manipulation is really tricky because the performance profile of pretty much everything changes frequently without rhyme or reason.