The Mill CPU is interesting here, in that it's a belt machine, so SSA is very close to what its native machine/assembly looks like. It basically takes what is currently register renaming and drops the layer of ISA registers, and just refers to the results of previous instructions relative to the current one. That sort of architecture would be almost trivial to JIT SSA for- you wouldn't even need register allocation, just instruction scheduling.
Another consideration to go along with decompiling hints, debug symbols, etc. is that web pages are very transparent and manipulable with the browser's inspector and JS console. Any new bytecode would ideally keep the ability to poke around the app's data and interface- it's a very nice REPL-type tool.
Stack machines tend to have small bytecode and it's relatively easy to write a small low-performance stack machine interpreter. Register machine bytecodes tend to take up more space, but it tends to be easier to write high performance interpreters and reasonable JITs. If you're always going to generate machine code, an SSA format minimizes the work/time necessary for a JIT to generate high-performing machine code, but it's difficult to write a high performance non-JITing interpreter for SSA-based bytecodes.
SpiderMonkey, Java, CPython, Forth, and SmallTalk (blue book) all use stack-based bytecodes. LuaJIT, Android's Dalvik, Squirelfish, and Parrot use register-based bytecodes. Michael Franz's SafeTSA (alternative JVM bytecode) and LLVM bitcode are compactly serialized SSA representations.
Microsoft has done some research on using arithmetically compressed syntax trees as an alternative JavaScript format. Part of me feels this is the best approach, as it speeds up transmission and parsing that all JavaScript engines have to do anyway, without performing transformations that JITs spend a fair amount of effort undoing later.
Ideally, I'd like to see a compressed SSA format, with optional debugging symbols and optional decompiling hints, analogous to WavPack's hybrid lossless audio format. The format could be losslessly expanded back into the original JavaScript source, or it could be stripped down to something like a binary with debugging symbols, or it could be further stripped down to just the data necessary to generate fast machine code.