I associate streams with infrastructure-related code. As such, I would not expect a use case to return a stream.
That being said, if the stream object is an interface or abstract class, you achieve decoupling. This still allows for polymorphism and mocking during unit tests. One of the goals of clean architecture is to make code easier to test. You could argue that an interface for a stream gives you testable code.
While I think you could get things to work using streams, I do believe it would be surprising to other developers since streams are more associated with network connectivity, file systems, and other forms of I/O — infrastructure. These are typically resources that require careful handling and cleanup to avoid memory leaks or locking a resource so that other processes cannot use it. To me, this communicates a different intent than what I think you are aiming for.
Events are the more idiomatic solution here, because they are a general solution in situations where a problem requires decoupling and/or asynchronous behavior. Some languages, like C#, have native support for events as a base-level feature of the language. For other languages, a simple list of callback functions or objects supporting a standardized interface can suffice. More generally, research event-driven programming for more information.
The nice thing about events is that the pattern does not assume which layer of the architecture you are in. Events are a good solution in many cases where some logic finishes processing at a later and unpredictable time, or in cases where you legitimately need to support concurrent programming. A related buzzword to consider when dealing with asynchronous business logic, especially when dealing with micro services, is eventual consistency.
That doesn't mean a stream isn't useful, or won't be part of the solution. If some other service running in a different process needs updates, streams could be a good solution, but more often these would take the form of some sort of network socket connection and message passing — think: message queues. At the point where your application communicates across processes or across the network, you are solidly in the "infrastructure" layer of clean architecture. Events raised by the domain or use case layers would likely have some infrastructure code as listeners, which might then update a stream object or send an HTTP message to another component.
So, the answer could be both: events in the use case and domain layers, where infrastructure code could be listening for those events. Upon responding to an event, the infrastructure code would likely use some sort of stream or socket to forward a message on to another process or service across the network. In your case, it could send a message back to the end user using a Web Socket.
A simpler alternative would be for the use case to return some sort of identifier that gets passed back to the user interface, and the client can poll the backend for status updates.
