Assume you are already given a properly-salted, password hash $X$ from some slow PBKDF (e.g., like Argon2id).
Now, you want to apply some large (~256-bit) secret "pepper" $S$ to it before storing it in the database.
Is there a significant difference between storing it as an $$\text{HMAC}\left(S,X\right)$$ (where $S$ is the secret key to the HMAC of $X$) versus a "much simpler/basic" $$H\left(S\mathbin\parallel X\right)$$
where $H$ is just some SHA-2? (e.g., SHA-256/512)
No for this scenario where the message is statically sized, using a HMAC is not required. You can use a sufficiently strong hash such as SHA-2 or SHA-3 instead if you must.
That said, it would probably be more neat to use a HMAC or even KDF. The advantage is that these algorithms do take input keying material as a separate parameter. This might be interesting if you want to keep the pepper secret; you could store it in a hardware device and use it for HMAC, for instance.
Currently you are using the hash as poor-man's KDF. So if you can spare a few cycles you might go for a more luxurious option like HKDF (which is based on HMAC).
