does work with shortcodes but NOT with

Good question. It stopped working for me ages ago, too. Which is a pity…

Ah thanks, @viper007bond. Hmm. You see, the main problem with shortcodes is that:

1. TinyMCE will often add lots of formatting codes in-between, e.g. P tags, line breaks, etc., and these will often (not always) be wrongly formatted by SyntaxHighlighter Evolved. Using WP always in text mode (not visual) is usually good enough to avoid this behaviour, but do a mistake once — launch an article in visual mode by mistake — and everything gets hopelessly broken — forever. The weird thing is that everything is correct inside the database (yes, I’ve checked), but SyntaxHighlighter Evolved still insists in all those P tags, line breaks, and assorted nonsense.
2. All other plugins use PRE/CODE tags or XHR. This means that switching between plugins will not require extensive changes. See the discussion on http://theme.fm/2011/11/locking-yourself-out-of-the-syntax-highlighter-evolved-plugin-2837/ Not something you wish to do often in a live site…

Aye, I agree that shortcodes is ‘better’ than having many JavaScript calls (especially because you can cache the formatted page… with JS-based PRE tags all has to happen live, when someone calls the page, although there is certainly no need for ‘dozens of JS files’, there are very small and efficient JS-based solutions). And one reason why I have been sticking with SyntaxHighlighter Evolved is that it’s easy to extend languages with additional plugins (and yes, I’ve contributed with one!) instead of manually hacking the plugin in order to support different languages. Also, in some plugins — for instance, those using Google Code Prettify — the JS might be stored on an external server and be impossible to modify to add support for further languages. So, in general, I really tend to prefer SyntaxHighlighter Evolved when it works. The problem is when it doesn’t!