Yeah, let's use a memory unsafe language, handle memory management by hand and just completely ignore the fact that no human being has ever managed to consistently write bullet-proof code in it.

Using software which automates memory management, engineered by the brightest minds on this topic, is for hipsters, right?

I guess you also roll your own crypto and implement stuff in assembler “for performance”?

"Since it has deterministic destructor and RAII is easy to implement, garbage collector is not needed"

This is kind of like saying, "x86 has CALL, PUSH, and POP operations, so there is no need for a language with subroutines! Just use inline assembly!" Garbage collectors are not strictly needed in any imperative language. The point of garbage collection is to enable programmers to think at a high level, without having to divert their attention to low-level issues.

"Also move schematics really helps with performance: create, copy & destroy can be avoided altogether. No garbage, nothing to collect."

Move semantics are a solution to an artificial problem. Sensible defaults like allocating objects on the heap and using references everywhere would have solved this problem and many others. Yes, I know that the C++ approach to programming is supposed to give programmers the power to do things for themselves, but that does not mean that the default semantics have to be brain-damaged. If code like this:

  std::vector<int> vec;

Caused an object to be allocated on the heap, and created a reference to that object, move semantics would not be needed. To stay true to the C++ way of doing things you could have a special non-reference type. Note, of course, that this really needs garbage collection to work well, and that the garbage collector would be entirely optional (as Bjarne Stroustrup suggested): programmers wanting to avoid the garbage collector would use non-reference types and pointers to non-reference types.

"Specifying the closure variables is optional and it is both for performance and encapsulation"

I am not seeing how it makes sense for either. Specifying anything about how variables are captured is a pointless exercise. Variables should just be captured if they are not shadowed, and they should always be captured as copies. When programmers need to capture by reference, they should just create a reference and capture that. Introducing another syntax just to declare how variables should be captured, and then making another nonsensical default behavior (no capture at all), is just silly.

"You don't need performance all the time - some are OK with 400 queries/sec, others want 7,000 on the same server"

You know, it is not a very strong argument when the top result (in C++) is only marginally faster than the next best (in Java). The fact that another C++ framework happens to be much further down, below systems written in Java, Scala, PHP, and Lua, is also not helping you. If anything, that test shows that the cost of using a high level language is not so bad; fantastic performance can be achieved without having to fumble around at a low level, and low level languages like C++ are not a guarantee of good performance.