As I said I’m not against it and I don’t think it’s set on stone for Logseq devs neither. I think it just happened that Logseq focuses on the Efficiency mindset and the UI for a more RDB experience is just lacking at the moment. If one contributes to Logseq in that direction with a good implementation I don’t think the devs will refuse it. Indeed properties are a step in that direction.
I mean one should use the best approach according to the problem, not the situation. For example if I want to track books and their authors the RDB model is better for me.
Again it depends on the problem: sometimes OOP is very naturally the best paradigm and sometimes it makes sense to use FP instead. It’s not like a developer will always use one or the other, of course.
In my opinion, compared to other applications, Logseq gives very abstract, general and powerful tools and the user is free to build a custom workflow . Indeed my “indexes” are a workaround that is possible thanks to the generic Logseq tools.
I don’t remember if I already mentioned it, but for example here there is my proposal to make it easier to add properties while keeping the efficiency approach: