Depends on the device.
A user program, when granted access, writes to the device's data interface.
There's also a control interface to the device, which is utilized by the device driver or by ioctl() calls from the user program.
Normally data written to a device cannot affect its control, but there are exceptions such as ESCape control sequences (used by printers and display terminals). Such devices have a simple or no HW control interface (e.g. perhaps a 3-wire serial connection), and sharing the data and control channel is necessary.
Such devices typically use ASCII-coded data, and a control sequence uses the ASCII ESC character as a prefix. Binary data (instead of ASCII text) will probably contain occasional bytes of decimal value 27, so that the subsequent bytes would be treated as a control sequence. So garbage data sent to such a device will produce unpredictable operation.
Other devices, such as audio devices and storage drives, have a much more sophisticated control interface or a protocol for its shared data & control channel (e.g. ATAPI protocol for ATA drives). Data written to the device is always clearly marked as and handled as data, and will not affect the device's operation. Of course, sending garbage data would clobber stored data somewhere on a disk drive. Or output high slew rates (e.g. square waves) to a speaker connected to the audio device.
/dev/zero to an audio device will probably produce maximum negative DC voltage to the speaker, which will sound like a thunk then silence. (Values to the DAC usually use biased representation; 0x8000 is a 16-bit value for zero volts.) Prolonged output may overheat the audio amplifier and speaker's voice coil.
Access to a device's firmware (for rewriting) is typically a protected operation. This would be true for char and block devices.
The previous comments refer to actual HW devices. Writing garbage to special device files such as
/dev/ports will be unpredictable and not advised.