Technically the .rxdata files are databases, they just aren't using an SQL server nor are they in a format that is used in SQL. Instead, they are binary serialized object storages. They arrays you get are structured in a way that you can access each object through it's ID as index in the array which is convenient. But anything beyond that has to be done with plain old iterations (e.g. if you want to get a list of items that inflict a certain status effect).
But let me explain why an SQL database here is unnecessary. First let me separate the object oriented model (basically every OO language out there including OO databases, I'll get to that) and relational model (SQL databases and tables that represent data in a different way).
Single-user applications should use simpler ways of storing data. This includes either simple binary serialized files, XML, JSON, human readable formats, etc. Marginally you could use an object oriented database that stores stuff into a special format and has a special query language for data access and filtering, but let's not go too deep into this topic because the practical usefulness is really limited as you actually only get the downsides of both OO and relational models.
Multi-user applications benefit from properly structured data. The relational model helps here as lot because the data is minimized, there are no duplicates (at least in theory, but it's sometimes used in practice for performance reasons, let's not go too deep in there either) and the data model is well defined so every application actually connecting to this database can easily represent this data in different ways either using the OO model or in a completely different way. The main advantage here is that data can be interconnected between different users. If you would save stuff on a file-per-user basis, you would have a hard time connecting data between users or you would require special files for interconnected data. See where this is going? If you have a file for every user's save data and a special file for the buddy lists between players, you're already gearing towards a relational model (e.g. with tables to represent data, because tables could almost be seen as files). If a player deletes a buddy, you would only have to change one file in that case. Otherwise you would have to open both files and change the buddy list of both players. While that may not seem like much of a problem, there is the problem of concurrency. What if one of the players was currently saving his progress? Suddenly you get a whole new set of problems (which is called concurrency, SQL database handles that in various ways) for which normal files are simply not suited. But sadly, this advantage of using a relational model obviously introduces a lot of complications such as relational-OO conversions of data when loading/saving stuff (the database has a relational model with tables and such while in the application you have to use objects to represent data because the relational model is difficult to use in programming and data representation in programs).
RMX-OS is an example of this. Many users connect to one server and their data is actually interconnected. It makes sense to use a database here instead of just a lot of files that would complicate things way too much in the end. The more files you would have to keep track of, the more difficult it gets. SQL databases on the other hand offer you a simple, opaque way to work with the interconnected data without having to think about concurrent access or duplicate data.