In terms of business ROI, RNNs may not only yield better results for the end-user, but may also lead to lower costs due to their simplicity. You may be able to replace a very complex hand-engineered system with a RNN that's easier and cheaper to maintain.
a) when data (particularly historically-oriented, time series-type data) becomes as accessible and as commoditized as `npm install <foo>` (e.g. `datawiz install <a-PB-sized-data-set-of-everything-that's-ever-happened-in-this-domain-ever>`), and
b) the realization that software engineers and data scientists work best when paired together; they're symbiotic roles, not competitive/opposing (e.g. think an F-14 pilot and RIO).
I wish every keystroke, every OS, every program, console, TTY, GUI, errno, ssh session, Window, RDP frame, TCP/IP packet... everything I ever did was logged and timestamped. Imagine pairing that level of data with an RNN and a feedback loop that could self-evaluate predictions.
(And then imagine if that could be anonymized and publicized, such that in 50-100 years from now, new developers could get a head start with a "friendly AI" that nurses them from "well, that segfaulted" to "end-to-end enterprise app implemented from scratch" over the course of their career.)
That being said, you've got this backwards. The natural outcome of hiring a bunch of rails/python devs to fine tune a machine learning / translation / recommendation system is that you get hundreds of thousands of lines of code that run slowly AND don't work. The entire premise of "deep" learning is that the system is a black box - features are learned by the black box. And you typically use pre-rolled fast GPU implementations. Most importantly, very little domain specific knowledge is needed. In fact, getting that hand-engineered system is going to be more complex, more costly, and it's going to require people with more domain expertise.