For those who are looking for the quick answer
Avoiding writing anything that modifies the JS DOM is always good practice, unless you have a good handle on exactly what is or is not going into the page, your likely going to run into a lot of trouble.
If you want the longer answer, keep reading
Unless your code and html is encapsulated in the new web component architecture, then when ever you call one of the various JS output methods, that's likely to modify anything the rest of the page flow may depend on, you're going to halt the DOM renderer and force it to wait while it checks everything.
Even if what you print out is not going to interfere with other elements in the page, the DOM renderer doesn't yet know this, (especially if it's still constructing things) and so will pause while it double checks what it does already know.
There are ways and means to mitigate this, for example you could output everything into a sandboxed I-Frame, then the only renderer that gets paused is the one in the I-Frame, or you can make sure that your script runs before anything else ever, produces its output, but keeps it hidden until the rest of the page is created.
Another reason that folks often overlook are things like Google advertising elements.
GAd's do some very, very funky stuff with the DOM, including busting themselves out of I-Frame containers and up the page tree to sit above other elements, so they can interact with them.
In a project I worked on previously, we where doing a LOT of work in this area, and the trouble GAd's caused us in scenarios like this was nothing short of maddening. And it's not just GAd's there are other things too, widgets from other providers, map widgets, web components and various scripts that try to hook up to things in sneaky ways.
Unless you know every single line of code your including in your page (Including that in 3rd party scripts) I'd strongly advise against doing this.
If your target is modern HTML5 based browsers and you don't care much for the older ones, then you might want to consider using the newly emerging web-components standard. It's designed exactly for this kind of scenario and is designed from the ground up to make sure you can wrap anything you need in your own little JS world and not harm anything running in the browser. This new technology is what makes things like the new Video and Audio players available with their own controls and skinning capabilities.
If you use 'PolymerJS' or 'X-Tags' to support your efforts, these things will work across the board right now, and adapt to use native features as the browser manufacturers start to enable this in their browsers.
If you're using Polymer, then even though officially the Docs state IE 10 or higher, you can get support using it all the way back to IE8, Chrome 30 and I cant remember the exact version, but a few versions back on Fire fox too.
If you're not able to use the newer web-component architecture, or you have to support really old browsers, and need to write contents out, then the absolute safest way is to lock your script away inside an I-Frame and keep it as physically separate as you possibly can from the rest of the page DOM.