Yes. V8 (and other Javascript JIT engines) are very good, with a lot of effort put into them by talented engineers. But there's a floor on performance imposed by the language's own semantics. Of course, if your program is I/O bound rather than CPU bound (especially at network-scale latencies), this may never be noticeable. But a Javascript program will use significantly more CPU, significantly more memory, and both CPU and memory usage will be significantly more variable and less predictable than a program written in C or Rust.

It's complicated, though mostly that complication doesn't change the overall conclusion.

Much of the language's semantics can be boiled away before JIT compilation, because that flexibility isn't in use at that time, which can be proven by a quick check before entering the hot code. (Or in the extreme, the JIT code doesn't check it at all, and the runtime invalidates that code lazily when an operation is performed that violates those preconditions.) Which thwarts people who do simple-minded comparisons of "what language is fastest at `for (i = 0; i < 10000000; i++) x += 7`?", because the runtime is entirely dominated by the hot loop, and the machine code for the hot loop is identical across all languages tested.

Still: you have to spend time JIT compiling. You have to do some dynamic checks in all but the innermost hot code. You have to materialize data in memory, even if just as a fallback, and you have to garbage collect periodically.

So I agree with your conclusion, except for perhaps un-nuanced use of the term "performance floor" -- there's really no elevated JS floor, at least not a global one; simple JS can generate the same or nearly the same machine code as equivalent C/C++/Rust, will use no more memory, and will never GC. But that floor only applies to a small subset of code (which can be the bulk of the runtime!), and the higher floor does kick in for everything else. So generally speaking, JS can only "be as fast" as non-managed languages for simple programs.

(I'll ignore the situations where the JIT can depend on stricter constraints at runtime than AOT-compiled languages, because I've never seen a real-world situation where it helps enough to counterbalance everything else.)