That makes a certain amount of sense. Traditionally software handshaking was only used for keyboard/terminal devices where on 'printable' character code were data and the control characters are reserved for control purposes. xon/xoff being done with ^Q/^S and the other control characters had defined meanings:

SOH (Start of Heading)
STX (Start of Text)
ETX (End of Text)
EOT (End of Transmission
ENQ (Enquire)
ACK (Acknowledge)
BEL (Bell)
BS  (Backspace)
HT  (Horizontal Tab)
VT  (Vertical Tab)
FF  (Form Feed)
SO  (Shift Out)
SI  (Shift In)
DLE (Data Link Escape)
DC1 (Device Control 1/X-On)
DC2 (Device Control 2)
DC3 (Device Control 3/X-off)
DC4 (Device Control 4)
NAK (Negative Acknowledgement)
SYN (Synchronous Idle)
ETB (End of Transmission Block)
CAN (Cancel)
EM  (End of Medium)
SUB (Substitute)
ESC (Escape)
FS  (File Separator)
GS  (Group Separator)
RS  (Record Separator)
US  (Unit Separator)
[download]

It's quite possible that the serial device driver retains special handling for some of those characters when xon is enabled.

With modern UARTs and FIFO buffering, handshaking is often unnecessary, at least at resonably low speeds, but if your device supports one of the flavours of hardware handshaking, it would be a good idea to enable that.