I cannot answer for their future plans, but in general, SQLite doesn't seem to be focusing on this kind of analytical workload at all. DuckDB would be a more likely bet in that space.
Indeed they write that the algorithm has been implemented in DuckDB.
It also probably is hard even to get the SQLite _executor_ to accept these plans, given that they are not trees. It feels a bit odd that none of the papers seem to really talk much about this; they have an algebraic tree structure and then end up with something that's distinctly a non-tree after a rewrite. I understand that for the typical column store execution model of doing an entire operator at a time, this isn't a problem -- but wouldn't it be for the rest of the optimization pipeline? Like, how do you build a join (hyper)graph from this? To what degree are other rewrites (like, well, pushdown) allowed? It's obviously been solved _somehow_, since already HyPer could do this and they claim to be able to run the plan in Postgres, but it's not immediately obvious to me. Do they insert a CTE and thus an optimization barrier?