TL; DR
Iterative time-boxing and estimation are the very foundations of Scrum. You can't "do Scrum" without incorporating these baseline concepts.
Prelude: Assessing Your Practices
Before addressing your question, it's necessary to examine your practices to see if they are really Scrum. We'll take them one by one.
I could not complete [a story] within iteration while it was planned to be completed.
This is Scrum.
Even when one follows the Scrum framework and implements its best practices, not every sprint will be a unqualified success. However, if you routinely handle work that can't be completed within the defined time-box, the Scrum Team is free to resize the time-boxes (e.g. increase sprint length) or reduce the number of story points they commit to each sprint.
I have just finished [the story] several days later after iteration ended.
This is not Scrum.
In theory, if your sprint just ended, you should be performing post-sprint activities like the Sprint Review or Sprint Retrospective, or have already moved into the next Sprint Planning cycle. In practice, maybe you did the work over the weekend after the Sprint Review but before the Sprint Planning session.
While that shows personal initiative, it violates the principle of keeping the costs of all work visible to the organization---it looks like "free" work from a project management perspective---and therefore contravenes the intent of the framework.
[T]he story should be thrown into backlog and revisited, but...it had to be completed anyway, reviewing it again would bring no new insights, etc.
This is not Scrum.
First of all, deciding what stories are still relevant to the project is the job of the Product Owner. Perhaps the company wants to shift priorities or reallocate resources, or maybe new information has come to light forcing a strategic shift in the project. By not providing the Product Owner the opportunity to re-prioritize the story, you undercut the organizational flexibility the framework is supposed to provide.
Secondly, Scrum is based on principles such as time-boxing, estimation, and inspect-and-adapt. If you ignore time-boxes, do not perform estimations, or do not inspect process failures and adapt to changes in your requirements then you aren't doing Scrum.
Thirdly, the Scrum framework requires that work be accounted for in order to product useful scheduling estimates. Either your work was done outside the boundaries of a sprint, or it was done in another sprint without consideration for the team capacity for that sprint. In both cases, this "invisible work" harms the framework and skews the metrics, making the scheduling process less reliable for rest of the team and the overall project.
In general, it appears that you aren't following the framework's guidelines. As a result, you and your team may not see the expected benefits of the framework, and will naturally question the usefulness of various Scrum practices and artifacts which don't appear to be adding value.
Your Core Question
[A]re there any practical benefits to using iterations as such and not just measuring velocity using story points?
You can't measure velocity without time-boxing your work into iterations. Even if you look at other historical measures of productivity, you will need to impose some form of periodicity to your calculations in order to derive a meaningful result.
In addition, velocity is a key metric for predicting team capacity for a given time-box. "Velocity" without time-boxing is often a synonym for management target; targets are goals, rather than useful measures of historical performance or future capacity.
Finally, if you discard iterations as a planning tool, you lose the ability to plan or schedule work in a meaningful way. While other frameworks like Kanban rely on average cycle times rather than time-boxed sprints for planning and tracking, all agile methodologies require iterations of some type to drive them.
