AVR Freaks

That's because pyupdi uses a very conservative timing. You can try to speed it up by going to the link.py file, in the init() function you have this line:

 self.stcs(constants.UPDI_CS_CTRLA, 1 << constants.UPDI_CTRLA_IBDLY_BIT)

replace by

 self.stcs(constants.UPDI_CS_CTRLA, (1 << constants.UPDI_CTRLA_IBDLY_BIT) + 0)

Then, increase that zero to 1, 2 3,... up to 7 it will get faster and faster and probably less and less stable (that number is GTVAL on the UPDI CTRLA register). You could also try to change the first 1 to zero to disable the inter-byte delay.

Exactly: not a single value. I've found recommended/common values of up to 115200, then it seems to double, but there is also a different series of baudrates. The AVR needs to support it, the USB-Serial adapter needs to support it, pyupdi may have a word to speak as well, or can I just make up values like 181937?

The FT232 chip has a fractional buadrate generate which will support almost any arbitrary speed. The UPDI interface also has a fractional baudrate generator which can handle almost any arbitrary speed. The UPDI will autodetect the baudrate from the SYNCH characters sent by the programmer.

Really? Oh, I see there are other places in the code that change CTRLA

    def st_ptr_inc16(self, data):
        """
            Store a 16-bit word value to the pointer location with pointer post-increment
    
            Disable acks when we do this, to reduce latency.
        """
        self.logger.info("ST16 to *ptr++")
        ctrla_ackon = 1 << constants.UPDI_CTRLA_IBDLY_BIT # with acks enabled.
        ctrla_ackoff = ctrla_ackon | (1 << constants.UPDI_CTRLA_RSD_BIT) # acks off. (RSD)
        # (Response signature disable)
        self.stcs(constants.UPDI_CS_CTRLA, ctrla_ackoff)
        self.updi_phy.send([constants.UPDI_PHY_SYNC, constants.UPDI_ST | constants.UPDI_PTR_INC |
                            constants.UPDI_DATA_16] )
        self.updi_phy.send(data) # No response expected.
        # Re-enable acks
        self.stcs(constants.UPDI_CS_CTRLA, ctrla_ackon)

See if adding 0-7 to the highlighted lines does anything.

I wrote a patch to pyupdi.py which significantly speeds it up by disabling acks for each block, mraardvark merged this patch last year. I assume you are using the latest version, which has that patch.

I am sure there is still a lot of scope for improvement, I noticed that the official Atmel tools (the attiny xplained boards) do flash much faster. This might be because their serial port has a lot less latency - they've got another avr chip in there running the programmer, rather than speaking updi directly.

I've also noticed that different seemingly identical USB-serial dongles seem to give different performance, I've not investigated this too much.

There is potentially a lot of sensitivity to latency on the usb stack, OS, and the serial dongle itself. Try a few different usb-serial dongles, and possibly, if you're running Windows, try using Linux, it might be better (or indeed, worse). Myself, I usually use a Linux VM in Windows, which probably the worst solution. Try a different USB port in the same machine, if it has several controllers.

Finally, maybe try a Raspberry Pi's uart port instead of a usb-serial (I've not tried that one myself)

Right now, it looks like mplab spends more time trying to decide whether it’s going to upgrade your firmware (eg for SNAP) than the “slow” programming  time you are reporting...