While working on the current story, one should also figure out what he has to do for the next story - Is this good advice?

With what we have here, this advice seems... weird to me. It's very common for engineers to be placed on 2 completely separate projects. In that case, it's quite possible for the 2 stories you need to do in a sprint to be completely unrelated.

That being said, here are some ways I can see this advice making sense:

1. The stories are dependent - As an example, here's a basic pair of tasks that are very connected: Make an API and then have an app/website call that API. If you're a decent full-stack engineer, you should think about how the client can cleanly call and consume the new endpoint and make a fitting client-server protocol accordingly.
2. There is a time constraint - Let's say you have 2 stories that you absolutely have to get done by a certain date. In this scenario, you should think about the remaining time you have as you're doing the 1st story - It's possible that you should do something like ship it with lower quality, so you can quickly switch over to the 2nd story to complete it on time.

Assuming good intent on your manager's behalf (and they're not just saying something to blame you), I could see this advice making sense in the scenario where you're working on a larger project, where there is a benefit to anticipating challenges and addressing them proactively.

Think about this as an extreme version of the Pareto Principle (aka 80/20 rule):

Can you spend 10 minutes discussing the next few stories in your docket with some people on the team who you respect? That 10 min conversation can change how you approach the problem and how you think about the priority.

If you look at the past few months of your work, can you think of instances where this kind of conversation ("planning") could have helped?