This is on purpose:
encryptedData.sessionVersion == session->getVersion() -> The same session, we should be able to decrypt
encryptedData.sessionVersion < session->getVersion() -> We have a newer session, we should ignore this message, that's why we're throwing a specific error to ignore in JS
encryptedData.sessionVersion > session->getVersion() -> We have an older session, this is a very rare edge case when there was a session reset from the other client but the session init message was not delivered, in that case, we want to throw an error to heal session state.

we do it always for numbers because JSI uses double when passing numbers from JS

I'm confused... it seems like you're saying that for both the < and > case, we should throw an error... but we're only throwing an error here for the < case, no?

For case < we should throw specific error, other than Olm's error to ignore this fact and avoid resetting the session.
For case > we should keep the default behavior which is decrypt, or on Olm error reset session. We're not throwing an error explicitly but Olm will do it (OLM_BAD_MESSAGE_MAC). If you think it's better to introduce another specific error - not ignored but causing resetting session like internal Olm errors I can do it as a follow-up, the logic will remain unchanged, this is just about code readability/avoiding calling the decrypt method.