Best approach for handling script tags?

To be honest, the best approach is to not do it at all.
Allowing scripts directly in the content is a security issue (and it's awkward to maintain), but if you feel it's worth the risk...
We don't officially support embedding forms into content since Drupal has the FAPI and modules like Webform with great ability to handle those things.

Later versions of TinyMCE will by default leave script tags alone (and wrap them in CDATA blocks), but if you've got our Teaser Break plugin active the scripts might get stripped out by the browser. See #510552: Invalid XHTML: missing trailing slashes, absolute urls and uppercase tags for other issues caused by letting the browser do all the HTML->DOM->HTML transformation. I created a feature branch in git for that issue, if you need Teaser Break you might want to give it a try. (Just note that it lags behind the main branches a bit.)

I tested with TinyMCE 3.4.7, left Teaser Break disabled, and it kept the script snippets.

All you'd need to do is disable the editor, paste the script, enable the editor and finally disable it again.
Then it runs through all the routines it does when content goes from being loaded to being submitted to the server again.
Just to be sure, I also went through the steps you listed above.

Do you have any plugins not shipped with TinyMCE itself enabled? (Such as Teaser Break, Wysiwyg Image Upload, IMCE Bridge etc.)

I have this issue too with script tags and the latest TinyMCE, CKEditor, and maybe others as I keep testing.

The script is definitely there with WYSIWYG profile off and definitely not there with it on.

Oops, I had Teaser Break on, now it's off and working.

I just turn all buttons on as it starts with none (?!). Having a random content-breaking button there does not make sense to me.

I found the same (and followed numerous troubleshooting steps found here and stackexchange and other places ) ...

I did NOT have the teaser-break on, but this report and others led me, by a process of elimination to find I had to
Disable the media.module "Media browser" button
and
Turn ON "Verify HTML" in "Cleanup and Output" - which was the opposite of what I'd expect.

After that, I could provide an input format that was able to let an (authorized) user use both tinymce via wysisyg AND embed script tags.

Notes : when I disabled the Drupal media browser button, inline scripts came back, but the 'src' attribute of a remote tag was still being stripped (!?)
It took toggling "Verify HTML" to do the opposite of what I thought it would do and ALLOW "potentially malicious" code through.

Drupal 7.24
WYSIWYG.module 7.x-2.2
media.module 7.x-2.0-alpha3
TinyMCE library 3.3.9.3

I have been wrestling with this same issue because I want to embed forms from formstack account using the script tag. Removing media button, button for wysiwyg line break module and teaser button worked for me. The "Verify HTML" had no effect on it. I confirmed after by testing with it enabled and disabled.

Media button is missed.

@Kcannick - I found that although disabling the media button did give me script tags back, and therefore seemed to let me do *inline* scripts, there was an additional issue with script tags that used external src URLs - and the "Verify HTML" step was necessary to get those working again.
If you are not using external scripts, you'd probably not see any difference, no.

Still, there may have been other conflicts that I was not able to pinpoint, I can only report what worked for me.

Raw HTML CCK Field (Drupal 6) - no filters, formats or editor

Simple Fix for Drupal 6! Just use plain text format. Then convert it back to html in a field .tpl when the node is built.

Plain Text format on a CCK field will convert the HTML tags to entity special characters (this would make is so it reads like code on the page instead of being actual html tags). It stores the string encoded using php's htmlspecialchars($text, ENT_QUOTES, 'UTF-8') inside of drupal's check_plain() function.

The cleanest simplest way to decode it, is in a field tpl file. This avoids hooks, hook order problems, looping bugs, and performance issues. This is done by adding tpl files to the base themes: hq_base, odyssey_base and odyssey_admin. Here is how drupal decodes plain text on a cck node edit form: print html_entity_decode(strip_tags($text), ENT_QUOTES); Note - html_entity_decode turns php tags into html comments when it decodes back to html. Here are sample files with the correct naming convention to give php control over the fields:
• content-field.tpl.php
• content-field-[your_field_name].tpl.php

content-field.tpl.php is a copy from the cck contrib into the theme folders, this is a contrib override to make it available in the theme, and should not be modified (unless you wanted to change all the fields in the theme). The field specific file is also a copy of the tpl, it will work once the override file is there. Then decode to html in the field tpl file:
• // print $item['view'];
• print html_entity_decode(strip_tags($item['view']), ENT_QUOTES);

Drupal Version Note:
The tpl files are slightly different in Drupal 7 and Drupal 8. But the html_entity_decode() is a php function that won't change per Drupal version.

Security Note:
This decode trick for getting raw HTML goes against the way Drupal was built for text formatting security. It means that anyone with permissions to edit the page now has permissions to edit html structure, and add script tags on the page. This can break layouts, and potentially be dangerous. You are relying on editing permissions for security here, instead of Drupal's normal Formats-per-Role security.

I would strongly advice against using editors with "plain text" because it's simply meant for anywhere you don't want to take any risks with potential markup in the content. "Manually" decoding plain text to HTML (even only in some circumstances) circumvents all of Drupal's content filtering and anything expecting to be able to output HTML as plain text (for examples etc) could mess things up badly. This practice could also seriously confuse a person taking over responsibility for a site, unless they are explicitly told about every place plain text could be interpreted as markup.

The -dev snapshots now have helper functions for using JavaScript regular expressions in implementations of hook_wysiwyg_editor_settings_alter(), see wysiwyg.api.php for details. RegExp are often used to specify [markup] patterns an editor needs to escape/hide while in WYSIWYG mode. Earlier it was not possible to configure these settings from the hook because RegExps can't be directly serialized into JSON and passed to the client. That won't help while Teaser Break plugin is active though, since the way it uses the browser's native methods of parsing and serializing the markup/DOM has some crazy consequences (which I'm hoping to resolve at some point by using a library for this, but there's another issue about that somewhere already).

@DamienMcKenna eep!
While your point is relevant, the idea of totally prohibiting script inline in the page and closing the question is way to heavy-handed.

There are now hundred (if not thousands) of online services that advertise simple embed snippets for easy daily content-manager use.
They explicitly are designed to be copy-pasted into the body of your page. Here's a simple one:

<script data-gittip-username="dman-coders"
        data-gittip-widget="giving"
        src="//gttp.co/v1.js"></script>

And there are similar widgets, both from the source and third party for for twitter, facebook, paypal, github, linkedin, flickr, youtube, gmap, polls, competitions, promotions, galleries etc etc. We need the freedom to use these.
Not all of them are great. A number of them can *also* be achieved by getting your developer to find and install one of the hundreds of Drupal single-service-specific integration modules each time - occasionally with better results, occasionally with worse.

While I do endorse code_per_node for some uses, it doesn't help at all with positioning elements inline.
It is frustrating for a content manager to follow the simple and accurate instructions given by a trusted web service provider, pasting in a snippet that does demonstrably work in other web tools, and have Drupal break it.

The primary security issue can obviously be covered by managing permissions to text filters, and that's a necessary step.
Not all third-party code is (IMO) trustworthy or a good thing to have on your site, but that is a different question, and one that CPN or similar will not help with either. The point is that when a content manager has the need to run a campaign or put a 'donate now' button in the middle of their page - it's not correct to prohibit that outright. Nor to write a one-use custom Drupal plugin that does no more than what the script already does anyway.

Script tags are a reality. The only reason they started failing - as reported in this issue - was due to a code conflict and some plugin rewrite messing things up accidentally.
That can be identified and fixed. Saying 'nobody should ever use inline script tags anyway' is not the solution to the problem.

Looks like @drywall has tracked the problem of disappearing script tags to using older versions of jQuery, in particular, anything less than jQuery 1.9.1 while also using a plugin (like Media).

See this: https://www.drupal.org/node/2242677

I have to agree with #13. I was most amazed by the attitude taken by #1. OK, I realise that Drupal relies heavily of people giving time voluntarily and fixes are only likely if there is a demand, but I for one am having to find alternatives to solving the inability to stop

After trying various techniques, #14, along with #1 from here https://www.drupal.org/project/ckeditor/issues/1950498, solved the issue for me. Just to be clear, #1 did not working without #14.