I wasn't part of the team which orginally created SLK so I don't know for sure the reasons, but this is my opinion on this.
1. In my opinion, having a separate database doesn't necessarily mean that it's not a real SharePoint solution. There's plenty of parts of SharePoint itself which have separate databases. Search immediately springs to mind which has several
databases, and other service applications do as well.
2. Although lists are very flexible, they are not relational databases. Some data just works better in a relational database. If you look at the SLK database there's around 40 tables with all their relations. This would be quite tricky
to work with in terms of list.
3. Security. In all these tables users should only have access to their own data. Although possible through item level permissions, this is going to be tricky to manage.
4. Performance. Given the complexity of the data, list access is likely to be a lot slower than database access.
5. Probably the killer reason is that the SLK can cross site collection boundarys. In this case you need a separate repository to store the data and a database makes a lot of sense here.
Given all that, I have started thinking about how to run purely within SharePoint so that it could be used in a hosted environment as a Sandboxed solution e.g. Office 365 for Education. This would take a lot of work to sort out though.