For server-side applications, then the answer is absolutely yes. Many large sites use C++ simply to provide the performance and resource usage that scripting languages don't. Many years ago a lot of web server code was written in C++ anyway (see things like Microsoft's ISAPI or ATLServer frameworks) or just as CGI applications. This changed when the web became more popular and needed faster development turnround. A script language is always going to be faster to develop, especially when you're just 'knocking something together', and was always very popular with junior developers getting in to programming.
As proof look to the most popular language for web development, PHP. Its a fine environment in which to work but no-one will say its the best language in the world.
Today, I'd hope that things have matured to a point where the server-side backend should be written with as much professional care as any other application. That means C++ can make a comeback in web development (and I think MS is going that way, as Herb Sutter reported that C++ will reduce the energy requirements in the data centre, which with huge datacentres we have today means a significant cost saving. Hence the C++ renaissance at MS, though I'm not convinced that'll turn into anything beyond system software for them)
One thing to note though: it is trivial to write C++ backend software that sit as services that are called from simple scripts on the web server. I did this with my old place of work - the web server was there solely to provide a pass-through to the application services. This allowed us to provide much better security (anyone hacking the exposed webserver got very little to work on), much better performance (as the business logic was distributed on servers that didn't web-serve), and they were very easy to test - the back-end services were stand-alone and provided explicit and well-defined interfaces so they could be tested without the web part of the total infrastructure.
I think this is a natural evolution of RPC mechanisms, where once we could run an object locally or remotely without (as a developer) caring where the object was located, now we can disconnect GUI from objects in a web browser rather than a desktop app.