I actually don't see a problem with using a document renderer for applications, assuming it's actually treated that way. The document-rendering of a browser is lower-level than a UI toolkit, and that makes it more powerful in a lot of ways. But we need to be able to build abstractions on top of it to actually build UIs. I think react.js's approach (or something similar) is actually pretty good here.
A lot of the problems we run into are people treating DOM nodes as if they were UI widgets, when in reality they are lower-level primitives for drawing and capturing input.
I've never heard conducting a MITM attack on the Internet backbone or hosting provider as "easy" before (other than by governments—but they probably already have plenty of vectors for generating fake certs). Now, if you're serving HTTP over an unknown wifi access point...
I guess it might depend which features of lombok you use. Lombok vals don't comply with the Java language spec so you might have issues there (as so many other tools e.g. IntelliJ). Friends don't let friends use Lombok...
Do you expect AutoRefactor to work with code using Lombok?
I did not try, but I don't expect so. Why? Because AFAIK, Lombok enabled code is not valid java code. So I don't expect that Eclipse JDT (basis for AutoRefactor) will be able to parse it. The only way to make this work would be to work on the code generated by Lombok, then do the round trip back to the original Lombok source.
If someone tries it out, I would be happy to read the feedback.
BTW I think AutoValue could work better thanks to the use of standard annotation pre processor.