I'm missing something. Why allow people to 'authenticate against [a machine] via ssh' at all if you don't want them to run any program there or use any ssh services on that machine?
(It seems one of the reasons you might want to allow someone an ssh account without a shell would be to give them a proxy with an internal IP address – a feature not a bug. Alternatively, it's possible every user casually ssh-enabled on these machines already had equivalent port-forwarding and shell capabilities on some other 'inside' machines, so this 'insecurity' is trivial.)
For example, you may be hosting a git repository on that machine and wish to allow ssh access, while limiting shell privileges for some developers (contractors vs full-time).
gitosis handles this with a single git account that has the public keys for the developers and the access rules set in the .conf. At that point, a developer doesn't need ssh to the git host. This is the infrastructure I believe kernel.org moved to after they were hacked.
I've seen applications (older, usually IT created, but sometimes "enterprise software") that use the passwd file for their own authentication. Remove the ability for a user to authenticate against the system and they no longer have access to the application.
It wouldn't surprise me if this server was involved with the school's student information system and did just that.
(It seems one of the reasons you might want to allow someone an ssh account without a shell would be to give them a proxy with an internal IP address – a feature not a bug. Alternatively, it's possible every user casually ssh-enabled on these machines already had equivalent port-forwarding and shell capabilities on some other 'inside' machines, so this 'insecurity' is trivial.)