My school wifi asks to 'trust' a certificate on Iphone's, does it this allow them to view SSL traffic?
It's ok. The certificate you installed and trusted is used to provide you secure authentication against their RADIUS server and prevent you from connecting to rogue RADIUS server. If someone decides to steal your Active Directory credentials by installing a rogue RADIUS server your phone will pop up with a warning that RADIUS certificate is not trusted.
By trusting this certificate you are not risking with anything else. This certificate can't be used by school to read your SSL traffic or attempt to MITM your SSL traffic. From what I read in your question, your school does it correctly and cares about your security.
Regarding your question: why your phone does not trust that certificate (which is certainly issued by trusted authority). RADIUS requires explicit trust to particular RADIUS authentication certificate, because you don't know what AP you are connecting to. Otherwise, an attacker could get certificate from other trusted CA vendor (say, Let's Encrypt) and use it to impersonate school RADIUS server and steal your credentials.
This is not an issue in SSL context, because you know what kind of certificate you expect, because you manually type web site name in address bar. In wi-fi don't know to which AP you are connected and to ensure that it is legitimate, AP should provide RADIUS certificate you explicitly trust.
My phone does not trust this by default it seems. Is it because this theoretically allows my school to decrypt SSL communications?
Based on your description no it does not.
If it really were from DigiCert, surely my phone would trust it?
The problem is that before you authenticate to the wireless network, you are not actually connected to the network and can't reach any other host. When your device attempts to authenticate, the EAP supplicant on your phone will only be communicating with the authentication server.
With most EAP methods used by 802.11 wireless, the server will present a certificate to the EAP supplicant and the supplicant must make a decision if it will pass your credentials (username/password) back to the server. Since your device isn't yet connected to the network, the EAP supplicant is working with limited knowledge.
At the minimum, unless certificate validation is disabled, the EAP supplicant will check that the certificate is a valid certificate issued from a trusted CA and that the hostname listed on the certificate matches the hostname of the authentication server.
With some EAP supplicants, you can also optionally configure a designated CA(s) as the issuer of the certificate (i.e. only from Thawte or Digicert) and/or specific hostnames for the authentication servers. Many mobile devices (phones, tablets, etc) do not have these options.
Without use those options or some other sort of check, your phone would automatically accept any authentication server that would provide a valid certificate with a matching hostname. This would make it easy for an attacker to impersonate your school's wireless network and capture credentials on their own "authentication server." The prompt for you to accept the certificate is your chance to approve or reject sending your credentials to the authentication server.
Once you have accepted the certificate the first time, you should only ever see the prompt again if your phone is presented a different certificate (or you delete and re-add the wireless profile). Some schools will have multiple authentication servers so it isn't unusual to see this multiple times. However if you ever find a certificate suspicious (i.e. "arubuwifi.jimbobscomputers.com"), you should not accept it.