No, SOAP is for businesses that need a clear data contract in place when doing inter-business data integration with real money on the table. That's why it's been used in business APIs for nearly a decade. REST has nothing that parallels the functionality of a WSDL and all the tooling that has been built up around WSDLs. Without a WSDL, you don't have a computer-interpretable spec for the presented API, you have a bunch of human readable documentation, and REST has a huge gap between principles imposed by the philosophy and the protocol that allows for a wide variety in how APIs are designed. I don't think you understand the whole code auto-generation thing; SOAP can't generate much of the client-side code. It might generate the function signatures or an object that has the methods presented by the API. On the server-side, you can usually auto-generate a WSDL from a class definition or vice versa, which is a handy way to start turning that data contract into an implementation.
SOAP isn't going anywhere in the big-business world, but for smaller businesses/apps that can play faster and looser with data integration, I absolutely agree that REST is a simpler and more pleasant choice to work with.