An alternative to your Applescript workaround (which did actually work for me) is something like the following:
def workaround_bug_on_focus_view(self, view):
window = view.window()
if sublime.platform() == 'osx':
path_to_sublime = '/Applications/Sublime Text.app/Contents/SharedSupport/bin/subl'
subprocess.call([path_to_sublime, '--command', ''])
Apparently, if you launch sublime without any arguments and you open a pipe to its stdin (even if the input is empty), it opens a new view containing whatever it read from stdin. And for whatever reason this seems to be unavoidable from python in sublime. At least I couldn't find a way to prevent subprocess from doing this. So that is the reason for the extra '--command' and '' arguments. They basically do nothing, but prevent stdin from being read. (You could also use view.file_name() instead of these two args, but views don't always have a backing file, so you'd hit the stdin issue.)
If you want a slightly less hard-coded version of the path_to_sublime, you could do something like:
path_to_sublime = os.path.join(os.path.dirname(os.path.dirname(sublime.__file__)), 'SharedSupport/bin/subl')
Maybe there's a better way to get sublime's path. I tried sublime.executable_path(), but that returns "/Applications/Sublime Text.app/Contents/MacOS/Sublime Text", and that launches a new instance of sublime, unfortunately.
And the reason for using subprocess.call instead of subprocess.Popen is that Popen() can leave a zombie process open (named "(subl)"). Not a big deal, but I happened to notice it, and was annoyed by it. call() shouldn't ever hang, but a timeout arg of 1, for example, could be used if you're paranoid.