The new session must have been opened in long polling.
Unless instructed to enforce it, the LSProxy uses long polling when it fails opening a streaming connection.
This is done to overcome cases in which streaming connections are not supported, but in case of a temporary block at network level, it is possible that our heuristics get deceived and that long polling is chosen also when not needed.

You can make sure of what happens by consulting the ConnectionStatusListener: after onStalled, you should notice a call to onPolling.
If your client application is certain that streaming is possible (for instance, because it was used previously), it could force a disconnection and reconnection, which hopefully will select streaming mode; LSProxy does not do that autonomously.

As far as the log is concerned, you have enabled a very fine-grained log, which logs upon each poll, hence it can become huge.
Unfortunately, it is not possible to have the LSProxy log differently in case of streaming or polling.
Again, only the application could perhaps overcome, by changing dynamically the log settings based on the context.

Apart from some inefficiency, the use of long polling may not affect the update flow.
Only in case of a high update rate you may observe some delays.