layout_builder.overrides.node.view access check causes slow queries

Thanks for reporting this issue, @a.milkovsky.

Does it help if the addition of the "Layout" operation only occurs on admin pages or the canonical route for the node (i.e., the node detail page)? Perhaps something like this?

/**
 * Implements hook_entity_operation().
 */
function layout_builder_additions_entity_operation(EntityInterface $entity) {
  $operations = [];

  $entity_type_id = $entity->getEntityTypeId();

  if ($entity->getEntityTypeId() !== 'node') {
    return $operations;
  }

  $route_match = \Drupal::service('current_route_match');
  $route = $route_match->getRouteObject();

  // Add 'Layout' operation for layout-enabled nodes with sufficient privileges in the admin and on canonical routes.
  if ($route && (\Drupal::service('router.admin_context')->isAdminRoute() || $route_match->getRouteName() === 'entity.node.canonical')) {
    $nid = $entity->id();
    $user_current = \Drupal::currentUser();
    $route_url = Url::fromRoute('layout_builder.overrides.node.view', ['node' => $nid]);

    // Check current user for access to the override route for the node.
    if ($route_url->access($user_current)) {
      $operations['layout'] = [
        'title' => t('Layout'),
        'url' => $route_url,
        'weight' => 50,
      ];
    }
  }

  return $operations;
}

I tested in my local with a new D11 install, and it continues to provide the operation at /admin/content and /node/<nid>.

Edit: I'm hoping that despite /admin/content being a view, the performance was more of an issue on the frontend of the site. Another option could be to have configuration that disables the functionality entirely so that the rest of the module is still usable.