Q0 : Is the precomputed key stream vulnerable to side-channel attacks like a lookup table for exemple ?
Of course not; once it is precomputed it sits in memory. Even if it is accessed, no actions are performed that depend on the randomized stream - other than the XOR with the plaintext of course. In principle that could be vulnerable, but since nothing is really location dependent, I guess that the risk is relatively low.
If the energy usage of the inputs of the XOR can be monitored then you can still leak information about the bits. E.g. if a large all zero plaintext is usually expected then you might be able to see an all one plaintext. Similarly on some systems even copying data can be dangerous, independent on the contents. So yeah, it depends on the system if side channels exist and if they are applicable at all.
And of course, if you store the key stream then anything accessing it breaks the scheme. The longer you store it, the higher the risk (e.g. against direct attacks against the RAM (Row hammer) or CPU (Spectre / Meltdown). You could of course argue that you're screwed even without a key stream if those apply...
If the precomputed key stream is very large like a few MB, it may be paged out to the disk, can another program access the key stream while it is in the disk like a file ( which will allow it to decrypt the corresponding plaintext easily
Generally not, as the OS will not allow a process to access another process memory. Of course, if you e.g. have an application server or virtualized system then other protections need to be in place. Beware that this doesn't say anything about the security of the page file if another system can be loaded. For that the page file should be encrypted and many operating systems at least contain that kind of functionality (if it is enabled by default is another matter).
Is there any other security issue with precomputing key streams ( real issues or wrong hypothesisies ) ?
Loosing sync would be one of my main issues. Also, a key stream directly used for CTR mode may indicate that the implementation is not authenticated.
Finally, AES is pretty fast on most processors. I would worry if the implementer would know what they were doing. It is likely that they e.g. use a managed implementation rather than a native / CPU supplied one. I would mainly use key streams to avoid latency issues rather than throughput issues.
