Is Agile Velocity dangerous?

given the uncertainty of which developer will pick them up. Indeed, a junior developer might take longer than a specialized senior. 

What would that so-called "senior" then do? Pick up another ticket...or help his or her fellow team members to limit and actually finish work in progress?

Some of these are valid concerns about estimation.

I don't think the uncertainty about who will do the work is a huge concern. If you are using group estimation techniques, this should come out in the conversation. If you build any kind of learning curve or slowness into all the backlog items, it'll average out over time.

The concern about the use of the estimate for monitoring performance or holding teams to commitments may be valid in some organizations. However, this highlights the difference between estimation and estimates. You can use estimation practices to check the size and understanding of the work without recording an estimate. If you don't write down an estimate, then there's nothing for the team to be held to.

If you're looking for alternatives, I'd recommend the flow metrics and the #NoEstimates movement. Daniel Vacanti has written three books about using flow metrics for predictability and forecasting completion of work - Actionable Agile Metrics for Predictability: An Introduction, When Will It Be Done?: Lean-Agile Forecasting to Answer Your Customers' Most Important Question, and Actionable Agile Metrics for Predictability: Volume II: Advanced Topics. Vasco Duarte's No Estimates is also a good read.

If you do want to dig into better estimation techniques, and specifically software estimation, I'd recommend Steve McConnell's Software Estimation: Demystifying the Black Art and George Dinwiddie's Software Estimation Without Guessing: Effective Planning in an Imperfect World.

At the end of the day, estimation is a tool. Estimates are a piece of data. There are benefits and risks to using a tool and benefits and liabilities to holding on to a piece of data. Maximizing the benefits while reducing the risks and liabilities can be important, and it's ultimately up to the team to decide what the best approach is in their context.

However, there's been intense debate among my colleagues because some fail to see the utility of estimating tickets, given the uncertainty of which developer will pick them up. Indeed, a junior developer might take longer than a specialized senior. 

Hi Ivan ...to give you an example let us consider a scenario of you travelling to your office. In this scenario story points/any estimation technique says you need to estimate the distance rather than the time you would take to reach office. The time will vary due to a lot of factors (mode of transportation, traffic conditions etc.). The idea here is that it is easier to have an agreement on the distance rather than the time it would take to reach office. 

When it comes to story points you should estimate the work (based on amount of work, complexity and risk) and you should not be thinking about who would do the work and how long will he/she would take to do it. You are right when you say that a senior developer may do it faster than a junior developer but when this work is given to a junior developer you can help him learn from the senior developer (try pair programming). There will be a learning curve for the junior developer here for sure and this is to be encouraged. If it suits move this piece of work at the start of the sprint so that you can accommodate the learning curve and at the same time, ensure the work is done by the end of the sprint. Over the next few sprints you will surely see an improvement in the work of the junior developer and probably he is able to deliver a done story independently (dont you think this is the real performance improvement).

Also you need to check linking estimates to individual performance, delivering value is the key and not how many story points a team/individual has accomplished. Estimates are used only for the purpose of forecasting (or adding some kind of guardrails when picking up work during the sprint).

1. It is human nature to estimate things.  We look at a big jar of pickles and say "that's a lot of pickles" but we don't say "there are 25 pickles in that jar".  We look at a plane in the sky and say "wow, that's really high" but we don't say "that plane is at 10235 feet above sea level".  Estimates are natural for humans to use.  It helps to grasp the enormity of something.
2. Estimates are also made at a specific point in time based upon information known at that time.  After you start working on something, there is usually new information obtained and the original estimate is no longer valid.
3. A synonym for estimate is the word guess.  

Take the 3 things above and think about your original question and how your team feels about estimation.  It may be that you are trying to put too much emphasis on them and should step back to take another look.  Use estimates so that the Developers can then estimate if they can get some body of work done during a Sprint timebox.  Then once work begins, forget all about the estimates and focus on getting the work that produces value done. 

I second @Thomas' recommendation of Daniel S. Vacanti's work.  I have used it to help a number of teams and organizations realize just how much work is being done, how valuable it is and how much they really don't understand about how the work is done.