This kind of thing is the whole point of having dll support in mirc. While i am not specifically apposed to having a GENERAL PURPOSE sql interface built into mirc, i think that refining it to one specific flavour would be a bad idea, especially given the huge popularity of more powerful sqld's such as mysql, psql, mssql, etc.
The problem with adding one is that it would immediatly open up request for all the other flavours to have native support as well, but on the other hand a generic form would also need to support multiple flavours because of the different authentication and secure communication methods used.
Should just be left to DLL's imo, the scripting would not become much easier if at all by having native support.
As far as mirc internally using sql to store data rather than ini files and memory, im not sure i believe your claim that reading from memory is slower than opening a file (just like ini files, an sql database is a physical file or files), performing the query, returning results, then closing the file again.
I have never run into any major limitation/issues/complications with the availible sqlite/mysql/etc dll's for mirc that would be solved or simplified by including the library in the mirc binary.
