Note that there's a distinct difference between "not being sure how to go about implementing reducer-based side effects", and "deliberately deciding to not have side effect management as part of the Redux core". Two specific quotes from Dan and Andrew's AMA on Hashnode show that it was a deliberate decision:

• Andrew: "The reason the middleware API exists in the first place is because we explicitly did not want to prescribe a particular solution for async. With Redux, we knew that the community would come up with a multitude of better async solutions that whatever we could have built in ourselves."
• Dan: "We didn’t want to prescribe something like this in Redux itself because we know a lot of people are not comfortable with learning Rx operators to do basic async stuff. It’s beneficial when your async logic is complex, but we didn’t really want to force every Redux user to learn Rx, so we intentionally kept middleware more flexible."

So, having side effects approaches not be built into the core was clearly a deliberate design decision.

There's obviously a lot of different ways to manage async behavior in JS. Callbacks, promises, async/await, observables, and much more. You're right that choosing a side effects approach is something Redux users need to do. This is both a strength and a bit of a pain point.

My React/Redux links list has a large section of articles on Redux side effects approaches, including many articles comparing different libraries. My own personal advice is to start with thunks, and if you need a more powerful async approach, using sagas or observables based on your preference for syntax. From your comments, it sounds like redux-loop is more what you're looking for.