Lots of people make games in Java, Flash/ActionScript, C#/XNA, Python, JavaScript, and many other languages.
You absolutely can create games without knowing C++.
But that is not quite what you asked.
Do you think c++ will be standard for many years to come (10-20) or will it be replaced since the hardware power is increasing so rapidly?
That is a dramatically different question.
The answer is 'yes', but only for some types of games.
There are many kinds of games. Most games, from Tic Tac Toe to Farmville, do not seriously tax the hardware. They can be written in any language you like. Some games fall into a very different class of software; these games fall into the range of High Performance Computing (HPC), and they push the limits of what computer hardware can do.
Although you can write non-HPC games in any languages, your choices are very limited when it comes to HPC games. Even C++ was shunned until the mid 1990s for HPC of all sorts.
Let's consider just one aspect of modern programming languages that is a real issue in high performance computing engines: The use of virtual functions.
Many common patterns in C++ such as the common use of virtual functions, such as using virtual accessors and mutators. On today's hardware the cost of a virtual function is roughly 7 nanoseconds over the cost of a direct function call; back in 1995 the cost was around 100 nanoseconds. But how big is that in the engine?
There has only been one real comprehensive study of the costs of the language, and it was done back in '96. A paper called The Direct Cost of Virtual Function Calls in C++ studied the actual cost in several compute-intensive open source solutions, and found that the "spend a median of 5.2% of their time and 3.7% of their instructions in dispatch code." There is no evidence that the numbers have changed dramatically since then.
For non-HPC games that 5% of your compute time is not an issue, the games have compute cycles to spare. But when you are working on a high performance engine, the simple use of virtual functions that cost you a 5% performance penalty is a real concern. You can certainly use virtual functions, but you do so in cases where alternate solutions are more expensive.
This is why many game programmers, especially game optimization engineers, tend to be stuck in a "C with classes" view of C++; the cost of the feature is incompatible with high performance computing.
It is not that the feature is bad. In most cases virtual functions are great. They reduce development time and solve many real problems. But they have a cost, and if you are in the middle of a performance-critical area the cost is frequently unacceptable.
It may not seem like much, but it does add up in performance critical code. Do you want 5% more eye candy?
That is just one issue of the many issues you get in a HPC game engine. HPC engines will continue to extract every cycle they can, even turning to hand-tuned assembly in those most performance critical loops. That is the nature of the type of game.
Video game consoles, the PS4 and XBox One, are going to be the standard for the next five or more years. These consoles focus on HPC games to maximize eye candy. The core engines will continue to be "C with classes". On the PC, there will always be AAA games that push the hardware to the limit. These are HPC games. They will also continue to be "C with classes" in their core engines.
As processors become more powerful games can do more without becoming HPC games, but that does not mean that HPC games will cease to exist.