The problem in many cases, even where I am now, is that there is always new development, new features, new products being worked on so that any framework of tests, even record and playback (which is a framework of sorts) is going to require 1) maintenance in order to make sure existing automation can continue to run and provide assurance of existing functionality and 2) new test development (even record and playback) in order to build in the new tests needed for the new functionality. The problem is always to try and strike that balance between building new test capabilities quickly and efficiently (solving point 2) but making sure those new test capabilities are easiest to maintain (solving point 1).
So, how do you convince the managers? Really, it's going to take time and effort on your part to gather metrics of how long it takes to create new tests using both the old framework and the new methodology. That's one metric and, unfortunately, that's going to show that record and playback is going to show very well there. But what you'll need then is additional metrics measuring how long it takes to maintain a suite of record and playback tests versus maintaining libraried code units and data driven/table driven framework. When a feature changes, how long does it take to update all those record and playback tests for that feature versus, when a feature changes, how long does it take to modify the framework for that feature?
Ultimately, it's the bottom line of how much the manager is spending to do something versus the value of what is being done. Both record and playback automation and framework automation have, for the most part, the same value... assurance of regression of existing product feature. So, you biggest "bang for the buck" is to measure and evaluate the expenditure.
Now, along with that, rather than trying to preserve the existing framework, get practical. As you said, the existing framework has room for improvement. Perhaps some of what they are implementing for record and playback can be adapted to improve the framework. Are some of the record and playback tests being created candidates for incorporating into the framework? Are there parts of the framework that can be enhanced to make maintaining and using it easier? The management is not going to listen well to "this is wrong and bad" without something to back it up with "here's a better way of doing it".
Finally, back it up with some good research and knowledgeable papers. One that I find really helps alot is this article I found that describes, in detail, what framework testing is, why it's important, and even challenges with lists of do's and don'ts the specific problems of record and playback. That article has at the end of it an exhaustive set of references as well that can be cross referenced, researched, and so on.