It is extremely unlikely that deploying TemplateStyles could result in any issue that would want us to temporarily disable it, but just in case, we should make disabling it easy. Simply turning off the extension would litter the code with visible <templatestyles> tags, so there should probably be a config flag to make it still recognize the tag but not act on it in any way. (Or maybe just a prepared config patch for overriding the parser callback, if that's easy to do.)
I think YAGNI applies here. Your feature flag should be easy enough to add if it's actually needed, as all that would really be needed to do what you propose would be to add a return ''; at the top of TemplateStylesHooks::handleTag(), and maybe something similar for TemplateStylesHooks::onParserAfterTidy() depending on what is inexplicably breaking.
Re-opening, Gergo to implement - this is based on product manager request as a risk mitigation. None of us believe this is particularly hard (although there are probably differences of opinion about YAGNI), although having a configuration variable might at least streamline things in case one wiki is having an issue but all the others are okay.
I think it would be helpful to explain what kinds of issues you think might be encountered that would require the use of this? Exceptions on every page view? Some exploit in the CSS sanitizer that allows for XSS? In either case I wouldn't really be worried about raw <templatestyles> tags in output, I'd be more concerned with clearing the parser cache and purging pages.