"LLVM IR was also never designed to be a portable, platform-independent, well-specified bytecode."

This is completely and utterly false in every way. This is exactly what it was meant to be, and is. Maybe you mean "it does not turn non-portable languages, like C, into portable ones".

This does not change whether it is a portable, platform independent, well-specified bytecode. This is even covered in the FAQ.

To your specific examples
TargetData is meant to deal with languages that have unavoidable target specific dependencies, like C. It is unnecessary in portable languages.

Download size is completely unrelated to a portable, platform-independent, well-specified bytecode, and is probably the absolutely most trivial thing to fix in the world if it was necessary. I'm not sure why one would even bring this up.

Undefined behavior is not necessarily bad. Most languages specify some amount of undefined behavior. This is done on purpose, to enable certain classes of optimizations.
Is your claim that asm.js has no undefined behavior?

emscripten certainly does, even in asm.js mode.

My guess is that you meant that asm.js has a bunch of properties that are statically verifiable, and it validates conformance at compile time. That is great, but not really the same as "no undefined behavior". At a glance, asm.js has undefined behavior. For example: "As JavaScript functions, they produce the undefined value, but asm.js code is not allowed to make use of this value"

A program that attempted to make use of it would exhibit undefined behavior. It would be noncomforming to the asm.js spec, in the same way that a program in LLVM IR that uses undefined behavior is noncomforming to the language specification. Again, you may mean that you statically verify this, which is great, but that does not mean the spec does not deal have undefined behavior. It just means you try to validate conformance at compile time (and note, the asm.js spec itself explains why it can't possibly accomplish no actual undefined behavior at runtime: ' In particular, reading out of bounds from a typed array produces undefined, and calling FFI functions may produce arbitrary JavaScript values.')

"I certainly don't think there will be any fundamental limitations 5 years from now."

If you didn't believe this, i'm sure y'all wouldn't be working on asm.js. :)

However, I strongly disagree.
What you are doing is not the first time someone has tried to do something like this (see, e.g., the SIMPLE IR and other IR's the McCat compiler used to use), and it won't be the last. Your claim essentially comes down to "this time for sure!". Sorry, but living in the world of compilers, i've seen and heard this too many times.
The truth is there are no magic bullets in compiler technology, and asm.js isn't one either. It's a set of tradeoffs. I don't believe this chosen set of tradeoffs come without fundamental limitations.

I guess we'll see whether you are right.

"> Not to mention, LLVM, and it's IR, certainly has more traction than "asm.js".

Not on the Web, which is the important thing here."

You can always define a target audience that likes your stuff more. So let's go this way: Researchers, compiler developers, and a very large contingent of companies care very strongly about LLVM and improving it.

I certainly wouldn't disagree with "worse is better" often wins, particularly on the web.