I did some digging. I've re-read the R6RS docs, and the Larceny, Racket, Ikarus, & Chez sources. I picked these older implementations because it's more likely their maintainers were involved in R6RS discussions. Additionally, I tested Guile.
The R6RS docs give no indication under what circumstances write! would be passed a zero-length buffer. One might guess that a put-bytevector with zero length may have been the intended trigger. The requirement in question is on the users of (SRFI 181), not the implementation. There is no requirement in R6RS or this SRFI on the implementation to invoke write! with a zero count.
Larceny, Ikarus, Chez, guile -- I've skimmed their sources and unless I missed something, I see no way write! would ever get called with a zero count. They all add a buffering layer on top of the custom methods when building the port and only non-empty buffers are passed to write!. Guile has lots of tests, some of which confirm that write! is NOT called with a zero count, and no tests to confirm that a zero count would or should occur.
Racket does not provide make-custom-*-*-port at all.
I ran tests with Chez, guile, and larceny - none could demonstrate a call write! with a zero count. I was able to enable buffered vs. unbuffered modes in chez & guile, also no zero-count calls. I was unable to build or find an ikarus executable to test.
Conjecture about motivations of the clause -- if the custom port was intended to convey line-discipline semantics (ie a tty), or datagram semantics, it might be useful for a put-bytevector of length zero to be reflected as something distinguishable on the receiving end. Alternatively, perhaps the author was erroneously aiming for symmetry with POSIX's read system call where zero bytes received indicates EOF.