You can have JOINs, but within individual actors. So for instance if this entire conversation tree was a single actor, you can have a full relational model to make queries with. But you can't do joins on comments over multiple threads.
This is the sacrifice ActorDB makes to be distributed.
1. A NoSQL database but with SQL as the API and some support for relations. This is quite nice because I have often found NoSQL APIs to be lacking in many aspects.
2. A set of fully relational databases that need to be managed and/or load balanced. This is a use case I have. If the system administration is significantly easier than the tools natively provided by Postgres, MySQL, etc, then I can see this being a valid use case. The use of SQLite does not concern me since it has legitimate downsides [1][2].
This is the sacrifice ActorDB makes to be distributed.