"I keep trying to get him to explain why he was reinventing sql, and never did get a clear answer to that."
SQL embeds in itself certain fundamental assumptions about operating so deep that you can't even see them. For instance, despite frequently being referred to as a "relational" query language, it requires some violations of the original relational logic. One example: The original relational logic looks a lot more like a tuple store where rows can freely contain arbitrary columns than the rigid row schema format that SQL so throughly assumes. For another, it has no concept of sharding, or indeed any other particular data-oriented structure of the database, which is simultaneously one of its strengths (it has survived precisely by not baking in such assumptions) but is also one of its weaknesses. If your database is sharded, for instance, there's nothing particularly in SQL itself that will guide you towards understanding whether you're writing a query that will or will not cross shards. You just have to "know". In fact there's a great deal of things about SQL performance that aren't reflected in the language and you just have to "know".
In theory, a new query language could potentially address these issues. In practice, what I've seen from "new" query languages has more to do with being "easy to implement" for the new store, and if that does or does not happen to meet any of these criteria, well wasn't that a happy coincidence. Someday I hope to see a well-considered sequel to SQL (no pun intended), but the way of thought that SQL affords has so thoroughly taken over the world that it is hard to see past it, much as it is hard to see past the von Neumann computer architecture into anything else. (I am not one of those people who think either von Neumann architecture or SQL are terrible and it all went wrong because we got stuck on them, but that's not to say they are the only way of doing business, either.)