As I understand, this scheme maps all I/O addresses in the range 0x80 to 0xbf to the serial port.
True
But what is the involvement of the /M1 signal here? From what I understand, that basically disables fetching opcodes from the serial port.
Again true (if that is somehow made possible at all). But it also protects the ACIA against falsely seeing an interrupt acknowledge as access.
But the Z80 can't do that anyhow.
Not fetching, but creating a combination of /M1 and /IORQ does happen during interrupts as active M1 and active IORQ signals an interrupt acknowledge cycle. Incorporating /M1 disables that the ACIA could feel accessed by some random value during such.
Insert: Interrupt Acceptance and Acknowledge
Interrupts are only recognized during an M1 cycle when accepted, two states are inserted after T2. The manual calls them wait states, but in reality it's an I/O access marked by /IORQ - except, no I/O address will be outputted. Devices have to detect the combination of /M1 (which is still held active, as we're still within machine cycle M1) and /IORQ as interrupt acknowledge and request for a vector (there is also no active /RD present).
This is already mentioned with the signal description on page 7 and 8 of the 1977 technical manual (*1):

I'm asking about this because I'm designing a computer around the RC2014 micro and
Cool.
I want to understand whether I can narrow this range down any.
In that case it's more about the software. As you mentioned,
- the ACIA will answer on any port pair between 080h and 0BEh.
- Is there an 'official' address, like 080h/081h, defined?
- Or are there guidelines suggesting that?
- Does existing software adhere to these guidelines?
After all, compatibility might be only of concern if your intention is to run existing software, written for the RC2014 without any modification. If this is not a goal, you're free to use any other address (in that case I'd suggest to go for full 16 bit decoding).
- Or is the 'knowledge' of this addresses confined to a few drivers or BIOS like routines and not (direct) used by other programs?
This would as well enable a better decoding, as you'd need to only patch/extend these drivers/BIOS routines to comply with your narrowed address range.
For this reason it would be good to also know which address is actually used by the Microsoft BASIC and Monitor ROMs that ship with the RC2014.
Well, unless there are fixed guidelines, noone may guarantee anything. So, as usual, a grep thru sources is your friend :))
*1 - The first stop, whenever in doubt about some signals, must be the data sheet page describing them. It will usually support previous assumption, or sometimes, really only sometimes, offer a complete new view :))
Next step that would be looking for timing diagrams. They are especially useful when it's about device addressing modes like here (for this case see p.16 of the 1977 technical manual).
Both sections are usually present in all data sheets and quite prominent in manuals.