Another use case is installations where there is heavy reliance on temporary tables in queries. Since you can't run queries that create temporary tables on servers that are binary replicas, this leaves the master (not horizontally scalable) or logical replicas
One issue is keeping the subscriber and the publisher schema identical. Running migrations on both the publisher and subscriber does not seem atomic to me, therefore I don't have a way to enforce consistency between the two. The use case is simple: schemas change all the time, and keeping two databases (or more!) in sync manually is tough.
Another issue is migrating large databases (in the terabytes) to a new version of Postgres with minimal downtime. Say it takes a week or two to sync up the subscriber with the publisher, we have to enforce a migration freeze for that duration. That's often inconvenient.
We often want to have a database with a subset of data of a particular table somewhere else, and logical replication is great, since it allows me to run write operations on the subscriber. Binary replication forces me to have two identical databases.
While I don't have an answer to your roadmap question, you've raised a different question for me.
What are you expecting to get from logical replication of DDL commands that is not served by binary replication? I ask because typically someone would want to use logical replication if they wanted triggers to fire on the subscriber, they only a subset of all tables replicated, etc.
Perhaps a better question would be "What problem are you trying to solve?" rather than focus on how you expected to solve that problem.