This issue is not present in the newest flow, so I'm assuming it can be ignored. I tried fixing it, but didn't manage to

Cannot spread object literal because  null or undefined [1] is incompatible with  undefined [2] in property `sessionID`.Flow(incompatible-type)

This issue is present in the newest flow.

Cannot assign object literal to `state` because  null or undefined [1] is incompatible with  undefined [2] in property `sessionID` of the indexer property of property `keyserverStore.keyserverInfos`.Flow(incompatible-type)

flow doesn't know which KeyserverInfo type keyserverInfos has. I couldn't fix this, but this code is very straightforward

What is the reason for using ... and $Exact<>?

Nit: can we name it keyserverInfoType or something more descriptive?

Can you make a task for it and add it to ENG-4283 so we don't forget about it?

Using ... makes the type behave more like an interface - it's possible to have a function that takes infos: BaseKeyserverInfos and pass any of WebKeyserverInfo or NativeKeyserverInfo to it (but only be able to access properties from BaseKeyserverInfo).
I used $Exact<> in WebKeyserverInfo and NativeKeyserverInfo, because we want those types to be exact, for better type checking.

I could have instead done:

export type BaseKeyserverInfo = {
  +cookie?: ?string,
};

export type WebKeyserverInfo = {
  ...BaseKeyserverInfo,
  +sessionID: ?string,
};

export type NativeKeyserverInfo = {
  ...BaseKeyserverInfo,
  +sessionID?: void,
};

it's just a bit less flexible. But since we have WebKeyserverInfo, NativeKeyserverInfo and KeyserverInfo in lib, I guess I can always use KeyserverInfo wherever I'd want to use BaseKeyserverInfo as an "interface". So if you think I should change it, then it shouldn't be a problem.
I'm not sure if there are any straighforward advantages of using the second approach?