For some special situations where I don't use swfObject or similar to insert flash content I've used this solution:
theElement.innerHTML = '<embed width="580" height="327" flashvars="xmlpath=test" bgcolor="#000000" scale="noscale" src="/flash/theFlash.swf" type="application/x-shockwave-flash"/>'; theElement.innerHTML += ""; //force IE and safari to render correctly
<id id="theElementToBeReplaced">The alternate content for non JS-capable UA</div>
Ok, I admit it doesn't look very nice. But I've found that it works in every browser I've encountered, and it's fast and simple, and this without the use of any twice cooked flash satay-solution or detection.
Is there any problem with this solution? Does it work in all environments (my tests, including those from Litmus says so)?
SWFObject allows you to detect the user's Flash version and run a seamless upgrade - this is useful if your expected user base is expected to use a version of flash older than that run on your site. For sites involving more complex flash integration, this feature is indispensable, forcing your users to the latest version available.
Additionally, using SWFObject allows a callback function on the success or failure of the flash load, and thus provide corresponding exit strategies. For example, you may have tracking in place that forces you to make an API call once the flash loaded successfully - you could integrate that into your flash object, but how much nicer to run a success callback function!
Skimming the SWFObject documentation reminds me of all the pro features of using it. Like you said, it still works to use rudimentary JS innerHTML writes, but the SWFObject expressInstall.swf and the programmatic feel it gives to adding flashvars and other parameters make it feel more natural.
Other than not degrading nicely with non-js-enabled UA's, that is really all SWFObject does for you. If you're unable to load SWFObject (or even jQuery) then I don't see any reason why you couldn't use this.