Yup. In fact to use MacTerminal 1.1, the protocol is set to XModem. The same is set under ClarisWorks. For whatever reason this did not work in ZTerm. While it may be XModem protocol, it is not MacTerminal 1.1 compatible, meaning it doesn't keep the resource forks intact in a way MacTerminal Xmodem understands them. This doesn't really surprise me as MacTerminal 2.2 is the highest version which can be used on a 128K, so the vintage version of XModem protocol it uses could be different than the a more modern and standardized version used in ZTerm. Also, MacTerminal 1.1 was a Mac-only legacy transfer protocol which was eliminated with ClarisWorks. I have to imagine that Apple modified the XTerm implementation to allow for encoding and decoding of the resource fork, and likely packet size, none of which would have been necessary on the original CP/M format, or PC driven variants which ZTerm claims to largely support. I just don't see anybody continuing a MacTerminal 1.1 legacy standard which was likely mostly usurped by more efficient ones in the late 80s.
On the other hand, I may not have had the settings adjusted exactly right on ZTerm, so it is worth obtaining the latest version and checking it out.
However, one thing Sheepshaver provides for that I do not believe Leopard does is the ability to use MFSLives to read from MFS disk images under the Finder (as Tiger allows). There is a certain amount of corruption that can occur when an HFS only FInder manipulates an originally MFS written file. Of course anything less than OS 8 on Sheepshaver will read an MFS file allowing that file to be loaded by SheepShaver. This also means all original disk images and Classic SEAs, and other archives, etc. can be kept and run in a "native" environment.