No need to say sorry.
I know I did not take any of what you wrote as such.
The reason I replied was that many who don’t know Prolog may see the comment
(SWI-)Prolog is not a replacement for a relational database without a lot of additional effort
and think that if they want to use Prolog with an SQL or relational database it will require a lot of additional effort. I was just expressing my personal view that I don’t find that to be the general case and noting some working examples. 
Well I now realize that you @jan have been making this point much better than me also with examples, over the years. I really don’t want to take anything away from SWI-Prolog which is much more than just a Prolog implementation (of those there are many).
To go back to specifics. What currently does not work “out of the box” for SWI-Prolog but is a given for a real relational database:
Every single one of these things can be implemented but it needs non-trivial amounts of work. Query optimization in particular is somehow inseparable from the fact that while normal Prolog has a defined operational semantics (what happens first and what next) SQL query language does not have that. As far as I understand this is also a major difference between Prolog and Datalog, even though Datalog is syntax-wise a strict subset of Prolog.
I don’t know. In theory you could write something like prolog/0 that would allow interaction by reading queries and executing them. I’m afraid it would be quite a bit of near code duplication to write yet another REPL. Alternatively one could create a Pengine for a session and keep interacting with this single Pengine rather than starting a new one for each query. It is technically not impossible. I fear it is more confusing than anything else though. Its surely not on my todo list. If someone wishes to sort it out I’m happy to merge the changes if they look fine. Whether we should enable it on the public server is another matter …
Are available using transactions. You still need some work to do 
True. Tabling can solve most of that. It could be made automatic (XSB has that, though Theresa didn’t advice me copying that as she was unhappy with the current state).
So yes, you are right. It needs quite a bit of work to get all this. In theory that could of course be in a couple of libraries. There are various ways to deal with all that though and the optimal choices depend on the use case. This isn’t all that new. There are also plenty database systems that apply for particular use cases and although SQL is declarative (at least if you avoid some extensions) it can make a huge difference in performance how you write a query 
Yes, in theory a wrong query plan is “a bug” but in practice “fine-tuning a query” is a black art and a lucrative business
Just to give a bit more context to my comments. I can’t tell what is better, Prolog-style fixed operational semantics + some amount of magic in clause indexing, or “declarative” queries and very explicit indexing + black-box query optimizations, as implemented by the major relational DB vendors.
However, from a technical point of view, it does seem more reasonable to be able to add the magic of the query optimization if you think you need it, through a library, and even better, to have access to the implementation. Here, by “access” I mean two things: a) the implementation is open source and b) it is written in a high-level language (Prolog) so it is in practice accessible.
SQL being as widely used as it is is probably a historical accident. Its main selling points (queries in a “natural language”, “declarative” etc) do fall apart if you scrutinize them. And SQL is a pain to parse or generate mechanically, and read and write by a person, nearly impossible to write reusable blocks, and so on.
Aaaand, there is this whole thing that has been ongoing for decades: https://en.wikipedia.org/wiki/D_(data_language_specification). This is just to demonstrate that people who are very invested in relational databases as a concept and a technology still do not think that SQL is any good whatsoever.