You are not entirely incorrect.. however.. the goal of something like RAML or Swagger is to provide a way to descriptively define an API, that hopefully tool developers will then build tools that parse that description into useful end results, such as generated code that can implement the API endpoints, or automated tests that can run against an implementation (or mock) to test that the API works as described.
To me, and many others, the real benefit, besides using these tools, is the ability to define every aspect of the API in one file (or group of related files), as a single source of truth, that then spawns/generates all the other facets that enable rapid development cycles that are easier to boot. Now, part of the problem with what I am saying is that there is no one tool vendor writing a complete set of tools that does everything. Thus, we are left having to pick the tools we want to use, and hope they play nice together, to give us that total package.
So in theory, if all the tools were available, what you are asking is possible. To some extent, it is now. You just have to add some manual intervention to piece together the steps. Ultimately,, someone may come along one day and offer a complete set of tools that handles documentation generation, code generation, test generation, etc. RAML 1.0 specifically adds a feature that would require every tool to agree to the same thing...e.g. annotations. As an example, there is no deprecation tag to use in RAML to specify an API is to be deprecated. It is easy, however, to add an annotation for that purpose. The problem is, every tool you want to use, from documentation, to code generation would need to know about that custom annotation, the exact name, its purpose, all agree to it, and then implement their parsing of it for each purpose. e.g. documentation would add some note/disclaimer about the API being deprecated, code generation would add necessary code details to allow it to be shown as deprecated, tests might offer a different route for deprecated API endpoints or no longer test them... something like that.
Anyway, for what it is worth, I have faith that the right set of tools will present sooner than later, especially for RAML 1.0, and most of them are usually open source, so it it not always difficult to contribute to them if needed. For me, just the definition and documentation alone is a big win, and code generation and tests is a nice add.