I’ll address this part of your question specifically. There aren’t any “problems” with using innerHTML per se—it’s efficient, fast, and direct. Quick & easy. It’s fine to use as long as you’re writing experimental HTML code on your local computer, or as long as you’re manually writing the HTML code that’s being inserted (and not taking it from somewhere else, like a form).
However, it’s not something that you should be using in production code on an actual website that’s deployed to the public at large. One of the biggest risks in using innerHTML is that the HTML you put in there has to be valid—i.e., it shouldn’t be improperly formed with the wrong characters or anything like that, because the HTML code isn’t checked for validity at all. It’s just accepted as-is and replaces whatever was there before it. So theoretically, if the HTML fragment that you’re inserting does happen to be broken, that could end up breaking your whole page.
And that’s only when you’re manually writing your HTML code for yourself—if you’re using innerHTML on a form to update another part of the page, that’s something you absolutely shouldn’t do because that’s a HUGE security risk. Malicious users could easily write up some HTML code to attack your website in that case.
The DOM manipulation methods, on the other hand, don’t pose this kind of security risk and help to make sure that your page stays valid and doesn’t break.
Also, using innerHTML won’t retain any event handlers, which is a side-effect you probably don’t want to have: https://stackoverflow.com/questions/595808/is-it-possible-to-append-to-innerhtml-without-destroying-descendants-event-list