Why both with points based estimation if you're doing capacity based sprint planning?

you are going to ask everyone how long the ticket will take

Why? If the Developers have estimated using story points, why wouldn't an understanding of story point capacity be enough?

So why not just estimate in hours when you initially refine the ticket - and then sprint planning is just a review/ratification of the initial time estimate?

If the Developers actually find it easier to do so, then of course they can.

Time or story points, there is no precision in these values if the work is complex. These are guesses that can be leveraged as a guide when Developers are pulling backlog items needed to achieve the Sprint Goal into their Sprint Backlog. 

The benefit of sizing during refinement can include the all important collaboration and conversation that occurs when Developers don't agree. This can result in better understanding of the work and improved readiness leading into Sprint Planning.

When you say "capacity based sprint planning" and "bringing in till you're at capacity" I wonder where the Sprint Goal fits within this. Is it important to "bring in" until Developers are at capacity, or is it more important to pull items needed for achieving the objective of the Sprint Goal? More items can be pulled in should the Sprint Goal be achieved. 

"Capacity-based Sprint Planning" doesn't imply hours. Capacity is a measure of the amount of work that a team can achieve. Measuring velocity in story points and comparing the forecast availability of the team for the upcoming Sprint to availability in past Sprints is just as much capacity-based planning as estimating hours, measuring completed work in hours, tracking hours worked, and forecasting available hours. If you're not considering the capacity of the team to do work - whether it's in hours or a percentage or just a notional increase/decrease - I don't see how you can effectively plan a Sprint.

It seems like the question here is more about estimating in two different units. I would consider any and all estimation waste. Spending the team's time to estimate does not add value nor is it necessary to deliver value to end-customers. Such waste, to the extent possible, should be reduced or eliminated from the process. If estimating once is waste, spending the time to think about estimates twice (and in two different units, no less) is also waste.

I really like the differing opinions above.  I agree somewhat with all of them.  

I am not sure where you got your understanding of Story Points but this article by Ron Jeffries, who is said to have created them, might give you some better insights into the origins.  

There is nothing in the Scrum Guide that says you have to use any specific method to estimate the items that are in your Product Backlog. In fact, the word "estimate" or any variations of the word is not used in the Scrum Guide.  So anything that you have heard or read is something that people have found useful but it is not part of the Scrum framework. 

I have worked with teams that used Story Points, T-shirt sizing, hour estimates, colors (yes, they wanted to be different), no estimation at all, and other various techniques.  All of them were successful at delivering usable increments of value in every Sprint. 

You are correct that the practice you are using is wasteful.  So, bring it up in a Retrospective and let the team discuss it.  After all, your team is the only one that knows what is best for themselves. 

During my work with few corporates, the common practice what I have seen is to use number of hours while estimating the story. in my personal opinion, it is better estimation and helps to compare the stories/tasks in more uniformed way.

The basic idea is to arrive at the better way of estimation. If using the hours helps in estimation, I don't see any reason to not use this. This works well with the team and serves the purpose.