Is all the alarmism around BadUSB really called for with respect to host devices?

BadUSB is largely overrated. It is a very, very old attack that simply got a lot of recent press coverage, like IDN homograph attacks or filename unicode reversal (or has that one not gotten press yet?). It's an issue, sure, but it is nothing new.

So, in theory, a terminal emulator would need to be opened, and a window would thus have to at least initially be normally [...]

Actually, there are quite a few ways to more covertly execute code. There was a DEF CON talk on this subject recently, showing ways that custom keyboards and mice could cheat at high-stakes video game tournaments by triggering the execution of cheat codes on the computer, despite the monitors being diligently monitored to ensure no one cheats.

There are other things malicious USB devices can do than just emulate an HID, such as attempting to exploit any of your multiple class drivers. How often do you think some obscure karaoke microphone driver has been audited for security issues?

Would rebooting at the least not be required to alter a workstation's boot sequence, firmware, BIOS, or other systems that cannot be completely sanitized simply by reinstalling one's operating systems?

Modification of the BIOS can compromise a system even without rebooting it. After resuming from suspend, the system re-reads several ACPI tables, including the executable DSDT. A modified DSDT can trigger arbitrary code execution as a computer resumes from sleep. I believe there are also ways to trigger execution of code on certain ACPI events such as plugging in a HDMI cable.

An emulated USB keyboard could, in theory, trigger such a reboot through key combos, and can perform malicious acts like disabling secure boot in the BIOS, assuming a BIOS administration password is not set. This is not likely an issue for anything but targeted attacks due to the variability of BIOSes.

Another issue is USB bus sniffing. USB (2.0) is a half-duplex broadcast protocol, which means that a USB slave addresses the host directly, but the host sends the response to all USB devices, and politely asks only the recipient to listen to it. Because of this, a malicious USB device can receive any data sent from the host to a USB slave on the same hub. This may or may not be a problem for you. If USB devices sniffing, say, data being sent to a USB WiFi antenna or an external USB hard drive is problematic for your threat model, then this is yet another thing USB device can do.

This is not an issue for USB 3.0 (SuperSpeed). According to this website, USB 3.0 is a dual-simplex unicast bus, meaning the xHCI hub is not exactly a hub so much as a switch. It will route USB packets to their intended destination rather than broadcasting them. This is meant to be a performance improvement, but it has an unintended security benefit as well.

The USB devices themselves, once infected, or even just connected to untrusted hosts, would seem impossible to ever trust again under any circumstances, impossible to knowably sanitizer or re-bless with confidence that there wasn't some deeply hidden, and thus undetected, malware infection still present on the device.

Assuming you don't open it up and read the firmware from the microcontroller, that is true. Compromised firmware can only be detected by reading it directly from hardware, with very few exceptions. It actually is not necessarily as stealthy as a software infection, as software can be made volatile, given advanced anti-debugging features, highly obfuscated, and delete individual components of itself after executing them. This is contrasted with maliciously modified firmware which is, fundamentally, completely inert and helpless when it is being analyzed. Simply checking the firmware against a known good copy is enough to verify that it has been modified.

But, the question remains, what is the salvageability of a host device's trustworthiness after being left unattended in the care of an evil maid

This seems like a different question from the one in the title. The answer depends on your threat model, so you need to take into account the capabilities of your adversary. Is the evil maid particularly skilled? How valuable are your assets? In China for example, corporate espionage is ubiquitous. Bringing a company laptop to a hotel in China can lend itself to a literal evil maid attack, sometimes with very high levels of sophistication. If you are simply bringing your laptop with your personal files to a friend's house, at most you would just want to make sure the drive is encrypted.

Note that you are able to perform measured boot, which mitigates evil maid attacks. This is done by having the TPM measure a read-only part of the BIOS called the CRTM. This chain of trust continues upward until the kernel itself is verified, which can then verify your filesystem. This technique makes it exceedingly hard to tamper with a system, even if you can modify the BIOS, option ROMs, the bootloader, etc. A TPM-based chain of trust:

is the situation any different following a device being connected to untrusted USB devices entirely while under owner-supervision in the age of BadUSB

Yes, for multiple reasons. First off, your computer's BIOS is extremely trusted, meaning that it is highly sensitive to tampering. A modified BIOS can inject code into your kernel, trap events using SMM, or even communicate over the network. A USB device on the other hand is limited to what class drivers your system supports. An emulated keyboard will not be able to guess your admin/root password or do anything that could not be done by a blind person on your computer.

In short, I am seeking validation of my conjecture that the dire need for retirement from production, security-critical employment of USB devices that leave owner control or connect to untrusted hosts is not applicable to workstation hosts which are connected to by untrusted USB devices.

Again, this depends entirely on threat model. USB device are far more likely to be abused to exploit a filesystem driver or partition table parser, despite such vectors involving advanced software exploitation. It is only a dire issue when using modern systems that support DCI, a form of low-level JTAG debugging ("probe mode", lower even than the Intel ME's "ring -3", although the ME can also be compromised using DCI) which can be done over USB on some systems whose BIOS vendors have forgotten to disable DCI support.

In summary, malicious USB devices can do any the following:

• Emulate HID devices like keyboards and mice ("BadUSB"). Mitigation involves configuring your computer to only accept USB devices acting as an HID from limited sources, e.g. using udev.
• Passively sniff content being sent from the host to a USB slave on the same hub. Isolate individual USB devices on different hubs if you do not want them to be able to sniff traffic going to them. Note that some newer computers' EHCI root hub is actually a virtual hub, part of the same physical xHCI root hub. The virtual hub operates in broadcast mode.
• Control the system with low-level debugging for BIOSes which do not lock DCI. Older firmware or a BIOS whose vendor locks the IA32_DEBUG_INTERFACE MSR is not directly affected, but may still be vulnerable to hijacking of the ME over DCI.
• Attempt to exploit filesystem drivers or USB class drivers through malicious input. Using a hardened kernel or reducing the amount of kernel drivers you support reduces this risk.

Whether or not this is a dire situation depends entirely on your threat model. You should not be plugging untrusted devices into your computer, regardless of the interface they use, and you should not assume an uncompromised device will remain that way when plugged into untrusted hosts. Using a USB device with read-only firmware can help reduce this specific risk.