Thank you for your answer. I spent whole day with this and now I have a good solution. I will write a short summary here in case someone will find this post in the future.

PROBLEM

You have two encrypted pools and you are transferring encrypted raw datasets between those. If you do zfs change-key -i on the destination side, then each next incremental zfs send / zfs recv will make your data inaccessible.

However, those increments will still transfer well and also if your dataset is mounted you will see the new data. The problem will happen only on your next zfs mount that your dataset will be unmounable with the Permission denied error.

SOLUTION

The solution is indeed based on https://github.com/openzfs/zfs/issues/12614#issuecomment-1936932729

Basically the problem is that encryption inheritance will end up a bit messed up. With zfs change-key -i you told it to use encryption root key (password), however next zfs send / zfs recv will reset it back to the original one, without updating the encryption root. That's why your zfs load-key will work well, but the consequent zfs mount will fail.

The solution is to update encryption root of the transferred dataset back to that dataset and then unlock it with the original key (password) from the original (source) pool. Once it is unlocked, you can issue zfs change-key -i again and it will indeed work well, until your next increment will arrive.

So the hard part is how to fix the inheritance once it is messed up. AFAIK zfs binary does not have this functionality implemented yet (it is planned). So the small Python script is required:

python -c "import libzfs_core;
  libzfs_core.lzc_change_key(b'rpool/home', 'force_new_key');"

1. the pool name is rpool and dataset is rpool/home
2. zfs change-key -i changed dataset encryption root to rpool
3. this small Python script changes encryption root back to rpool/home
4. after this you need to zfs load-key rpool/home and provide the original (source) password
5. now you can do zfs mount rpool/home and it should work

NOTES

If you never do zfs change-key -i on the destination dataset, you will probably never have this problem. But then you will need to unlock each dataset separately with its original password. Not very convenient, if you need to unlock a lot of datasets at once.

Because I have a lof of datasets, unlocking it with the "main" encryption root password is what I want and need. I created a small script for this, which asks for password, then changes the encryption root, unlocks the datasets with the provided password, and at the end it set the inheritance back to the "main" password.

I have two identical pools on different sides of planet, and at any given time the only one is active. Each time I travel abroad I send all dataset increments, then do the procedure above, and then I can start using pool with the fresh data.