I only partly agree with the above.
I do think that tasking is something that can sometimes be dropped as a Scrum team matures. Tasking is best used early on when it provides a means to accelerate a team's understanding of the processes, dependencies and typical workloads associated with delivering a story.
Why do it?
Because it gives you metrics (e.g. burn-down) that flag up problems within a sprint, helps the team learn and helps spot and remove impediments. It helps you understand at a detailed level the mechanisms of delivering a story, leading to more velocity more quickly.
Why not do it?
Because it costs a lot of time. It may seem like a small job to task out and revise hours remaining - but it can take man-days out of a sprint.
So for me, it's worth doing in a new team or a new project - but you have to spot the point where you're no longer getting value for the time invested. At that point, drop back to stories only and see how it goes.
I hope that helps.
So where do I disagree with the above?
Well, tasks and stories are NOTHING alike.
A story is the "What and Why", a task is just the "How". The two must never overlap, as you have to maintain the independence of requirement and solution. The product owner has to own the story. The team have to own the tasks.
Any overlap or confusion between the two suggests, to me, something being very wrong in the dynamics of the process - usually too much influence on the 'what and why' from the techs, and/or too much influence on the 'how' from the product owner. And that's never good!