Just deploy an EAP application on OpenShift, via EAP (8 or XP 5) Helm Charts.
You'll see the server becomes ready almost immediately, i.e. according to the usual boot time - let's say a few seconds, while the Pod will be ready after one minute.

Looking at the Deployment resource configuration, this seems to be due to the InitialDelaySeconds value for the liveness and startup probe, which seems to be clashing with the readiness concept. Why should this initial delay in liveness cause a delay in readiness?

Then, please notice that the same will happen each time e.g.: a scale down and up operation is performed, or when a pod is restarted after sudden failure.

Waiting 1 minute after a runtime is ready seems to be a critical limitation in cloud native environments and such waiting time should be reduced to the bare minimum in order to provide the best performance in high-availability contexts.

Finally, why is the startup probe definition pointing at health/live ?

A potential fix PR is linked if the bug is confirmed.