"If" is not an analysis.
You're not asking a concrete question. You're dreaming up possibilities and pondering what the world would be like if those possibilities were actually relevant. That's not a productive approach on how to implement the current requirements of your application.
What you're doing is the equivalent of saying "I have to design a new T-shirt. But what if people had 3 arms?". It's an interesting thought exercise but it adds nothing of value to the current work you have to do to design a T-shirt for 2-armed people.
Rather than focus on the things you can imagine, focus on the things you know for a fact. Then decide your implementation based on the actual tangible requirements.
Let's say I store the total kilometers for that user, and update after each run, so base the achievement on the total km number set in his profile
This is the simplest implementation that works for the badge you need.
but this limits me to only a simple badge
But it's the badge you needed to implement. If it's "only a simple badge", and that is somehow a problem, then why are you trying to implement this badge to begin with?
what if I wanted a badge that is awarded when a user runs a 100km per week, 4 weeks in a row?
Do you need such a badge? If you do, then track the data you need to observe the badge completion (in this case, storing the last 4 week totals would suffice).
If you don't, then why theorize about it? Pondering features that you don't need is not productive when trying to consider how to implement the features you do need.
what if we're tracking the data of not one but a group of people?
The same response applies here. Is this actually something you need or not? Because there's no point discussing how to implement a feature you don't need.
If you do need it, then this needs proper analysis. How is a group defined? Can people belong to several groups? If so, does their personal progress get shared with all groups? Is the group badge based on personal minimums for everyone, a group total, a group average, ...?
This is an unanalyzed point. But whatever the analysis finds, the end result will always be to track the data that is relevant to observe badge completion.
Should I use an in-memory storage to keep all relevant data closeby? For example memcached or redis?
This question has nothing to do with which data you need to store to track a certain badge's completion. What you store and where you store it are unrelated topics.
Using Event Sourcing (which I know nothing about), would this be beneficial?
There is nothing in your question that leads me to believe event sourcing would add functionality that is (a) necessary and (b) not already available.
If I want to keep into account that badges can be added/removed and modified in retrospect
If you want the ability to retroactively apply future badges, that means that you need to store all data. Any data you fail to store is going to lead to the inability to create a badge in the future that relies on this data (that you won't have anymore).
You really need to outweigh the hassle and performance hit of storing every possible snippet of data, the odds that you're going to need that data in the future, and the consequences of not having that data when you do implement a future badge that needs it. Don't forget to account for all that effort you're going to spend on data that you're actually never going to use, if you never end up creating a badge that requires this data.
This is not objectively answerable by a random stranger on the internet. This is a matter of you deciding what matters to you.