First of all, I forgot that by default a Home Assistant sequence of actions will stop if one of the actions produces an error. I was reminded of that when one of my two Atom devices wasn't plugged in when I was testing the other one. Doh! There are two ways to deal with that. You can mark an action as "continue_on_error", or you can nest the actions inside a "parallel" operator. Because the actions that I can ignore are independent of each other (calling services to fiddle with the LED on the Atom devices or the D1 Mini), I chose to make them parallel.

I took all of the actions in my automation and moved them to a script. That gives me the option of calling the script from a triggered automation (such as a button press on an Atom device) or from some other Home Assistant mechanism. I know I will do the former; for the latter, I may use it to implement scheduled hot water recirculation.

I set the mode of the script to "queued" so it can be executed serially no matter if the calls to it are overlapped during the script's built-in time delay. If the normal time for running the recirculation pump is 5 minutes, then running the script twice will give 10 minutes without the caller having to wait around. To run the pump for an hour at some scheduled time, I can just call the script 12 times (assuming I have set the queue limit high enough). Since the triggered automation now just calls the script, it doesn't matter too much what its mode is. Or, rather, there is no setting that is ideal for all scenarios. I settled on setting it to parallel mode.

I mentioned earlier that I set the delay to 15 seconds for testing. I have now split that into two separate time delays. For testing, it's 5 seconds and 15 seconds. Why did I do that? A feature of the Navient HotButton mode is that additional button presses are ignored while the recirculation pump is running. The first time delay will be set to match whatever I configure on the water heater, which is some whole number of minutes. The second time delay is just a little extra padding to make sure I don't push the button slightly before the end of the water heater's timer and have it ignored. I could have combined them into a single larger timeout, but this way makes the padding a little bit more explicit, and I'm less likely to forget to have it.

Here is what the script looks like:

And in YAML:

alias: Tankless button cycle
sequence:
  - type: turn_on
    device_id: da742fda4419ea3eccda23997c5ab988
    entity_id: 9b27a85bafa2c633454c89970c4d166c
    domain: switch
  - parallel:
      - data: {}
        action: esphome.hotbuttonkb_set_led_hot
        continue_on_error: true
      - data: {}
        action: esphome.hotbuttonmb_set_led_hot
        continue_on_error: true
      - type: turn_on
        device_id: da742fda4419ea3eccda23997c5ab988
        entity_id: 412c31fd16a227e11078d9c0d04396ff
        domain: switch
        continue_on_error: true
  - delay:
      hours: 0
      minutes: 2
      seconds: 0
      milliseconds: 0
  - delay:
      hours: 0
      minutes: 0
      seconds: 15
      milliseconds: 0
  - parallel:
      - data: {}
        action: esphome.hotbuttonkb_set_led_cold
        continue_on_error: true
      - data: {}
        action: esphome.hotbuttonmb_set_led_cold
        continue_on_error: true
      - type: turn_off
        device_id: da742fda4419ea3eccda23997c5ab988
        entity_id: 412c31fd16a227e11078d9c0d04396ff
        domain: switch
        continue_on_error: true
mode: queued
icon: mdi:hot-tub
max: 15

Of course, the automation is correspondingly simpler:

and in YAML: 

alias: Tankless hot button
description: Press the button, get hot water
trigger:
  - platform: state
    entity_id:
      - binary_sensor.hotbuttonkb_button
    from: "off"
    to: "on"
  - platform: state
    entity_id:
      - binary_sensor.hotbuttonmb_button
    from: "off"
    to: "on"
  - platform: state
    entity_id:
      - binary_sensor.hotbuttonrelay_button
    from: "off"
    to: "on"
condition: []
action:
  - service: script.tankless_button_cycle
    data: {}
mode: parallel
max: 10

UPDATE: I got the "continue on error" stuff slightly wrong in the original automation. I've updated the YAML to reflect my correction. In a nutshell, I had to sprinkle "continue_on_error: true" in a lot more places.