Current status

The Sling IDE tooling project has been restructured from an Eclipse-only build with Tycho to a build that holds several subtrees:

...

I've done a quick spike and implemented a LSP client and server using LSP4J. The implementation was relatively straightforward and allowed me to explore the implications of going the LSP route. Currently LSP is very much geared towards implementing generic editor services, with some additions used for running workspace-wide operations. There is no support for defining IDE models which we can use for the content navigator and the properties views. Therefore the LSP route is not viable for our current needs. Also there is little to be gained by reusing the LSP4J runtime to create a client-server split, since we would have to implement the client part for each IDE.

Update: as of 2019-02-07 I was made aware via email that there is a way to add navigator support with the LSP, quoting:

The JDT-LS does this in VSCode: they implemented some specific URIs patterns that the send as documentSymbols or workspaceSymbols through LSP to populate the navigator. AFAIK, this would require some development in Eclipse LSP4E to support similar patterns, but if it happens to be generic and reusable enough, it'd be a good addition to Eclipse LSP4E and other clients.