I believe openHABian supports Pine64 out of the box. But if not, the manual install of openHABian will work on any Debian based distro. I’ve used openHABian on an Armbian running on a BananaPi without problem.
It depends on what else you have running on your RPi. From what has been described, the OH 1.x Compatibility Layer is almost a separate copy of OH 1.8 running on your OH 2 Karaf. Remove that, perhaps it frees up enough to run it as a separate application instead of as a bundle inside the one Karaf.
To raise a more philosophical question, what is the responsibility of any software project to provide backwards compatibility? You have extreme cases like Microsoft Windows where one can almost run just about any software created for Windows in the last 20 years still. Then you have phones like Android and iPhone. On a lark I tried to get my old Moto Droid (the one with the slide out keyboard) to run. Nothing worked.
Losing backward compatibility does come at a cost in loss of users for sure, perhaps loss of developers too. But maintaining backward compatibility comes at a cost to and I’m hearing from the developers that they are no longer willing to pay that cost.
It’s not ideal, but I can’t think of a better compromise than what is proposed, running multiple instances of OH and federating to retain support for the bindings that no one has been willing to migrate to the new architecture (for what ever reasons).
But it will have more RAM. 
And I wouldn’t expect OH 3.0 to be released too much before 2020 either. The timing might work out nicely.
And to directly address CalDav, there has been work in David’s PaperUI-NG study to bring more CalDav capabilities into OH proper which might be suitable for replacing this binding. The devil is in the details of course.