Maybe it won't be a difference for something like Redis (i.e. O(1) for any key) but it will be a performance hit for a sql containing hundreds of thousands of row, am I right?
Of course, if you're really concerned about it, you can easily put together a test. I suspect other latencies in your app would be larger than those due to the difference between integer lookup and text lookup. But like I said: if you're highly sensitive to performance, you'll want to be measuring against your application, your stack, regardless of advice you might read about on the internet.
If beautiful URIs are a priority, you can use a separate mapping table or service (memcache? Redis?) that maps the URI to a database ID. Of course, this adds latency/overhead as well. This could also give you flexibility in supporting multiple slugs for a single story.
People generally want (permanent) URIs to resources such as articles to be unchanging as you don't want links to break. This means that once you decide on a slug, you can't change it. If you want some correspondence between titles and slugs, this also constrains changing the title.
Including an arbitrary, context independent id in the URI means you can use that to look up the article and you're free to change the slug. You're not using the slug as part of the key used to look up the article in the database.
This also explains why using a hash of the slug would be effectively the same as using the slug itself, and with the same constraints.