wow... that's an interesting interpretation.
I'm well known for coming away from things with a different understanding than the masses. See why I think HTML 5, OOCSS, LESS, SASS, Bootstrap, jQuery, Yui, Dreamweaver, and a whole host of other things that are popular and trendy are a bunch of halfwit BS that I pity anyone who is forced to use because their boss only knows it as a sick buzzword, and have little if any pity for the people who are DUMB ENOUGH to use any of them by choice.
There will always be apologists defending outdated, outmoded and just crappy ways of doing things; innerHTML is just another item on the stack of bull in all but the rarest of cases; just like nyetscape 4 style accessing of form elements by name, using getElementxxx EVERY time you access something inside a loop or even in the same program (hence the idiocy of how jQuery does selectors), and the whole host of other 1990's practices that continue to plod on mindlessly to this day.
Of course, JHVH forbid you actually say that --what with the thin skinned wussies who run to the nearest authority figure "WAH, WAH, SOMEBODY SAID SOMETHING NEGATIVE!!!" like 7 year olds on the playground.
-- edit -- which is not to say I won't use innerHTML either, as I said there are RARE cases where it can/should be used, a great example being when plugging content into an element that is NOT on the DOM yet, since it will be parsed, then you can attach it as a constructed node AFTER; since it is parsed separate from the reflow, it works just as fast if not faster than a pure DOM only solution -- so you're right, just another tool in the toolbox; the key is knowing when the negatives outweigh the positives... most of the time when there are negatives it's because of a whole bunch of endless pointless annoying string additions.
Be a lot more useful if JS strings were whitespace neutral like PHP ones are.