Companies who want to legally use open source libraries must account for each dependency in their product, even transitive dependencies. This is especially true if your product is not itself open source. There are legal obligations to be met. Several licenses require user-visible notices, for example.
So companies often have some sort of spreadsheet or database or document somewhere that lists out every dependency and its license and legal obligations. Smaller companies without a lot of resources want this list to be as short as possible. Guava developers are trying to accommodate them by cramming everything into one jar file.
What they missed is companies often don't do this audit by jar file, but by some automated tool based on a dependencies.lock file or similar, because we need to know why the dependency is there. So we suddenly get this weird empty listenablefuture dependency and have to spend a ton of time understanding and explaining it, and a bunch of builds get broken and have to have it explicitly excluded, where a regular listenablefuture package would have barely been noticed.
In other words, in attempting a compromise, they managed to get the worst of both worlds. They created an extra dependency people must still account for, without actually gaining the modularity benefits of physically removing the code from guava. The only people happy with this change are those who have been wanting to just use listenablefuture without pulling in the massive, incohesive guava library.