That protocol document makes me think in terms of option 2, not option 1. You don't have a useful lower-level concept of "packet boundary", and you do actually have the same needs as a tagged protocol, since there's no guarantee that a given DATA frame is a reply to the most recently sent frame (and, indeed, if you're pipelining as per that document, it often won't be).
If I were working with that device, I'd use tokio_util::codec to allow me to have an enum SentFrame and enum ReceivedFrame that reflect the data going back and forth in a structured fashion, and a way to encode and decode that into byte streams for the serial port.