Why does broadcast_refresh need to be in a background job?

1

From the source turbo-rails/app/models/concerns/turbo/broadcastable.rb at main · hotwired/turbo-rails · GitHub

# As a rule, you should use the <tt>_later</tt> versions of everything except for remove when broadcasting
# within a real-time path, like a controller or model, since all those updates require a rendering step, which can slow down
# execution. You don't need to do this for remove, since only the dom id for the model is used.

# ... snip
# Same as <tt>#broadcasts_refreshes_to</tt>, but the designated stream for page refreshes is automatically set to
# the current model, for creates - to the model plural name, which can be overriden by passing <tt>stream</tt>.
def broadcasts_refreshes(stream = model_name.plural)
  after_create_commit  -> { broadcast_refresh_later_to(stream) }
  after_update_commit  -> { broadcast_refresh_later }
  after_destroy_commit -> { broadcast_refresh }
end

Why is an update commit queued in a background job, but the destroy commit done inline? The comment suggests that later should be used for anything blocking requiring rendering, but the refresh turbo stream tag doesn’t require any rendering:

<turbo-stream action="refresh"></turbo-stream>
2

Could be because it’s not around later - as it’s just been destroyed ?