The question is confusing, as C and C++ are languages, while JVM is a virtual machine and .Net is a platform. Scala could be implemented in C or C++, and it could generate machine code instead of bytecode for a virtual machine.
Answering the question that was asked:
Scala was not implemented in C or C++ because Scala, the language in which it is actually implemented, is a much better language.
Why is it better? Well, go read about Odersky's goals for the Scala language.
Answering the question that may have been intended:
Scala generates primarily JVM bytecode because that provides great portability as well as features such as a reliable and efficient garbage collector, run-time optimizations and just-in-time compilation by the JVM.
Let me repeat that last thing: JVM will compile to machine code hot spots in the code it is running. That's compile just like C and C++ compilers do.
There are other virtual machines available, but Odersky, Scala's creator, was already very familiar with JVM. He intended to have CLR as an alternative, but the effort to get that going hasn't achieved success yet.
Answering the question that could/should have been asked:
Compiling to machine code doesn't provide enough benefits over compiling to JVM bytecode.
It is certainly possible to generate microbenchmarks in C or C++ that beat JVM-equivalents. It is also true that extremely optimized code in C or C++ will beat extremely optimized code in Java or Scala. The difference isn't all that great, however, for long-running program.
Note that Scala isn't a particularly good scripting language precisely because the overhead for short-running programs is too big.
However, in most cases the speed of development and ease of maintenance are more important than the speed of execution. In those cases, where people are more concerned in writing very high level code that is easily understand and change, the run-time optimizations provided by the JVM may easily beat compile-time optimizations made by C or C++ compilers, making JVM (and CLR) the target that will actually execute faster.
So, no matter whether the question was about Scala compiler being a machine code executable, or Scala programs being machine code, the potential speed gains do not, necessarily, translate into real speed gains.
And, by the way,
I'll give you a counter-example: Haskell. Haskell generates machine code, and, yet, Haskell programs fare worse on Debian's shootout than Scala's. Given that, can anyone be sure Scala programs would be faster if compiled directly to machine code?
If you want an academic viewpoint, read this paper. If you are thinking about Scala, read Odersky and friends’ overview where they discuss what makes Scala scalable. There’s also a related question.
In a nutshell, Scala has features such as operator overloading, user-defined classes, traits, and many others, that allow one to express many domain-specific problems in a very natural way.
Best Answer
When Martin Odersky talks about scala as a scalable language choice, what he means is that the language itself is appropriate for:
He is most certainly not referring to scalability from the perspective of performance!
The fact that he can claim that scala is as appropriate for quick'n'dirty scripting as it is for large-scale enterprise deployment is roughly as follows:
Scripting
Scala is great for scripting because its type inference and functional style make it both concise and great for slicing and dicing collections etc.
Applications
Scala is great for writing applications because it is a statically type checked language with some great features for working in both functional and imperative styles. Scala is compatible with Java and hence you can leverage an enormous ecosystem of libraries.
Enterprise Deployment
Scala compiles to bytecode and runs on the Java Virtual Machine, a stable system with great performance, when compared to (so-called) dynamically typed (i.e. untyped) languages. Again, the fact that it is statically typed means that refactoring is made much easier on large codebases.