A typical X.509 certificate is the combination of data (including a public key $Pub_B$), and of a signature $Sig_A$ of that data, to be verified with an unrelated public key $Pub_A$. In order for the verifier to know which hash to use when verifying $Sig_A$, there is use for a field in said data specifying the hash used by $Sig_A$, and that's the purpose of signatureAlgorithm in said data. As RFC 3279 puts it:
Certificates and CRLs conforming to RFC 3280 may be signed with any public key signature algorithm. The certificate or CRL indicates the algorithm through an algorithm identifier which appears in the signatureAlgorithm field within the Certificate or CertificateList.
The signatures that will be verified with $Pub_B$ (produced with the corresponding private key by the certificate holder) use a hash (in your case, SHA-256) that may be different from the one used by $Pub_A$.
The signatureAlgorithm field remains useful after the signature $Sig_A$ is verified, since the trust we can have in $Pub_B$, and in anything signed using $Pub_B$, depends on how much we trust that hash.
Note: typical security "proofs" for digital signatures silently assume that a single hash is used in conjunction with a given key, and that the verifier knows which. It would therefore make a lot of sense that a certificate introduces $Pub_B$ only on the condition that it used to verify signatures in conjunction with a specified hash, or/and that by default that hash defaults to what was used in the certificate and is indicated by signatureAlgorithm; and I'm ready to bet that some PKIs using the X.509 certificate format do this.