Adding a fix for these 3 lines has made me realized the importance of a Traversal Engine in JavaFX. Most of the heavy lifting was already done by @JonathanGiles in JDK-8091673. @Maxoudela @eugener Do you think its worth pursuing this?

What was the purpose of these 3 lines?

AFAIU, it disables the Parent nodes in a custom control from receiving focus. However, the child (non-parent) nodes can still receive focus.

It was implemented as a fix for #713 by @effad

I can confirm what @abhinayagarwal has said about these lines. The issue-number #522 refers to BitBucket-Issues (no longer existant ...).
I also would appreciate if the TraversalEngine would be part of the public API. After all, the above lines are very hacky :-).

Do we care about thread-safety? If so, then it's possible that the button is removed between lines 175 and 176, resulting in a NullPointerException. Thoughts on an OOP alternative that upholds encapsulation? Maybe it's not possible, but something like:

actionBar.giveButtonFocus(OK_BUTTON);  // OK_BUTTON constant = 0

That would eliminate the need for the conditional (in this method anyway). The actionsBar class would need a method like:

private final Object mutex = new Object();

public void giveButtonFocus( final int index ) {
  final var buttons = getButtons();

  // Don't allow multiple threads to enter this block. This would have to
  // be sync'd on removal. Or use a synchronized collection.
  synchronized( mutex ) {
    // index is 0-based, size starts at 1 if not empty, so use >
    if( buttons.size() > index ) {
      buttons.get( index ).requestFocus();
    }
  }
}

That's then reusable, thread-safe, and will throw neither an NullPointerException nor an ArrayIndexOutOfBounds exception.

JavaFX is a single threaded GUI framework i.e. all scene-graph activities are done on the JavaFX application thread. Therefore, activities like removing of nodes, focus etc. are all inherently executed synchronously.