Network applications are usually quite robust with respect to disk space exhaustion; they will just continue. Some features may stop working, but overall service is not affected.
However, system logging depends very much on the availability of free disk space. If the disk is full, logging simply stops. Therefore, an attacker trying to subvert a network service without leaving any visible traces of the attack itself may try to disable logging first. For instance, by filling up the disk first.9.4
I don't know if this attack is practical at all, and if this issue has played any significant role in an attack. However, you should bear this possibility in mind when designing your application.
One example that is particularly careless in this respect, and surprising, is PHP. When calling a PHP script with a specific set of parameters, the PHP interpreter recognizes that the remote client wants to upload a file, and arranges for transmission of the entire file, and writes it to a temporary file on disk even before executing the specified PHP script.
If your application accepts large amounts of remote data (usually file uploads), you should require clients to authenticate first, so that you can at least find out who trashed your disk and trash the perpetrator in turn. If the service is anonymous, your application should have a configuration switch to set the maximum disk usage. If that limit is reached, it should reject further data uploads. In itself, this constitutes a denial of service against the application, but that is still preferable to disabling system logging.