These certificates are the trust anchors. They allow you to verify signatures and therefore establish trust in the messages that have been exchanged. (This is very similar to trusted CA certificates that are configured in your browser for authenticating certificates of HTTPS sites.)
The SAML requests and responses should be signed (the responses at the very least). You'll find elements like
<ds:DigestValue /> and
<ds:SignatureValue /> (although this may be simplified if you're using the HTTP redirect binding).
When the SP gets a SAML response from the IdP via the browser, it must verify that the signature it gets comes from an IdP it knows and what signed using the IdP's private key; this signature can be verified against the IdP's public key in the certificate configured in the metadata.
For an SP, failing to do this makes the whole process worthless, and being able to accept any assertion without verifying the authenticity of the IdP's message suggests a configuration error.
On the IdP side, it's less important to a degree. It's only necessary if the IdP wishes to verify that the request really comes from an SP it trusts. It's particularly useful if the SP requests certain confidential attributes to be disclosed (that not all SPs should see), and possibly to encrypt those attributes in the response so that only this SP can read it.
This being said, Shibboleth can release these attributes through a back-channel (the attribute service), where a connection between the SP and the IdP is made directly (without message exchanges with the browser). Authentication between the SP and IdP should still take place in this event, but I think it might work at the transport level (e.g. client-cert authentication) instead of message level (via SAML signatures), I'm not sure. Either way, you would also need to set up trust anchors for this.