I think you're basically correct. A language runtime is already a fully flexible data-driven system. It takes one piece of data (the program) and uses it to determine how it should act on other data. It might even have a multi-user scheme to store code for re-use by other programs (ranging from an include path to proper install management).
A "scripting language", roughly speaking, is a language runtime where this code input is human-readable. A compiler places an extra step between the user and the runtime. "Joke" languages like Malbolge and APL needn't be human-readable in any form. But it's all the same thing at one level, and anyway human-readable does not mean that all potential users have the skills to read or write it, or can be expected to develop them.
There are good reasons why you don't normally expose a language runtime directly to end-users. The main one being that removing flexibility increases convenience.
If I want to type a SO post, I just want to type it. I'm perfectly capable of instead writing a C++ program to output it, but I would not use a web browser that exposed a C++ program editor instead of a regular text box. People who don't know C++ not only wouldn't use the browser, they couldn't.
If I want to configure certain business parameters then I don't necessarily want to do that using a Turing-complete specification language, and even if I did this is probably not distinguishable from "hard-coding" those same business parameters in any other programming language. You still need to consider whether what you're writing means what you want it to mean. You still need to test that changes are correct. That is, you still need programming skills for any tasks that are non-trivial and not anticipated by someone who does have programming skills who prepared a specialised sub-system ("application") for you to configure ("use").
So if you're about to embark on a 100% data-driven system, that can do anything given the right data, you have two questions to ask yourself:
- Are we in the business of inventing programming languages, or should we be?
- Will our new programming language be better (for our purposes) than the ones we already have and will we support and develop it as it needs?
Sometimes the answers are yes, and you write a domain-specific language of some kind. Or even a real general-purpose programming language if you're Sun/Microsoft/Stroustrup/van Rossum/many others. Sometimes the answers are no and you have the "inner platform" effect -- after much effort and trial and error you end up with something. If you're lucky it's only slightly inferior to the programming language you wrote it in, and no easier to use.
Some languages are harder or easier to use than others, in particular if they are specialised to a purpose like R then some users will find them much easier. What you probably won't do, is make general applications programming fundamentally easier. At any one time there are probably several people/organizations in the world with the potential to do that, but your boss/company has to honestly consider whether or not that includes him/you.
There's a trick often used for games, which is to expose Lua bindings to the game engine. This allows designers to program in a relatively easy language, but still engage a "real" programmer where necessary for performance or to access particular functionality of the engine or the platform. The resulting Lua scripts are "data" as far as the engine is concerned. They don't all need to include much of what you'd call "logic" as opposed to config data, and often they pretty much define all the plot and environment, but not the whole gameplay. This is not 100% data-driven and it certainly isn't 100% error-free, but it's an interesting practical compromise.