The access token you receive that is not a JWT is likely an access token only suitable to call very specific API’s in the Auth0 service itself. In particular, it should be usable to call the /userinfo endpoint to get some info about the user, mostly the same information you would be able to already get from validating an ID token.
The use of IdP-initiated flows to translate a SAML IdP-initiated response into an OIDC one is indeed not the general recommendation. Given parseHash is mostly a client-side operation the fact that you call that method or not before a checkSession operation should be irrelevant.
In other words it’s unexpected for checkSession to be influenced in any way by the fact that parseHash was called before so the different outcome may be due to something else. However, it’s hard to guess so the best approach would be for you to try to compare the flows at the network level (HTTP traces) to see if you spot any difference between when it works and when it does not.