In normal operation Jobe shouldn't run out of disk space. It's essentially a stateless server so it doesn't store files - it merely caches them to save repeated uploads of the same file. There's a cache cleaner that runs if the volume containing the file cachedirectory (/home/jobe/files) gets more than 95% full; it simply discards any files more than 2 days old. This is a pretty crude heuristic and could be refined if necessary but we've certainly never had file space issues on our jobe servers, which stay up for years in a row.
There are however a couple of ways an attacker could run the system out of disk space, temporarily at least. One is by uploading large files to one of the temp directories. Such an attack would be effective only temporarily and would affect only jobs that were running concurrently with the attack job. This issue is discussed at length in the documentation (here) which does indeed suggest that paranoid sysadmins could consider setting disk quotas for the various jobe users. I do think it's a very remote risk, though, and assuming your jobe server is accessed only from CodeRunner it would be easy to figure out who was attacking you.
The other way of running file space down would be for users to make use of the new file-attachment capability, which allows students to attach files to their job submissions. Since any uploaded file is cached on Jobe and there is a limited file upload size set by the question author (defaulting to 1 kB) users would have to make thousands or even millions of different submissions to have any significant effect on the file store, unless the question author explicitly allows very large files to be uploaded (not recommended, for obvious reasons).