I'd like to see those articles from 2018 that say that LRA could be a single point of failure. Will you provide links? But do note that the LRA spec and therefore its implementation are not yet finalised. When they are we will provide documentation on the best practices for using LRA.
It is true that in the event of failure the system cannot make progress until the storage and application or "LRA coordinator" become available again but that is not a single point of failure, though I do acknowledge that availability will be compromised until the system is back up again. But this is no different from conventional transaction managers in the sense that all TMs rely on some form of persistent storage in order to recover from failures. The JTA transaction manager in the EAP product  is such an example and it also relies on persistent storage so in the event of a failure the application needs to be restarted.
When the LRA specification is released, the plan is to provide an implementation that runs on EAP and Quarkus. Like all EAP versions, production level support will be provided once it is out of the tech preview phase.
Until then you need to ensure that the transaction log storage is accessible. If you use a standalone coordinator then that needs access to the log storage and services need to be able to access the coordinator. If you bundle the coordinator with the application then it is your responsibility to manage the storage (for example you could do this by running your application in an app server).