From my experience, the opposite is true: New things are discovered during sprints, but at that point it's already too late because that work item has already been estimated in the sprint planning (most of the time incorrectly). Also the arbitrary sprint deadlines don't help either.
Will it mess up the numbers? Absolutely, but only for that piece. And as a result of the change of plans being entered into the current sprint (with something perhaps bumped to make room, or maybe the work itself bumped to a later sprint to give more time to plan for the new challenges) you already have a new estimate. And you have a paper trail of what happened and how you dealt with it.
Your velocity goes down and you lose some predictability, but your agility goes up because you can adjust instantly to new challenges. None of these tools are a panacea; you have to thoughtfully decide which trade-offs will offer the greatest benefit for your particular project.
The "deadlines" shouldn't be thought of as hard deadlines. They're estimates of what you expect to have done at the end of some arbitrary period. Your accuracy in this should be measured statistically over time. If it turns out that you're consistently under or over, you adjust how you estimate. Ideally you want your estimates to average out to break-even over the course of a year. The point isn't to be able to determine exactly how much work you'll do, but rather to determine with a high degree of confidence (80%? 90%?) when the work will be done, with the understanding that it's not guaranteed (i.e. it's a point statistic). It's a planning tool, not a performance measure (the moment you treat it as a performance measure, it becomes useless due to the cobra effect).
If your development situation has high enough stability that kanban will be the best fit, you'll get much more reliable metrics for planning, but less flexibility when something unexpected happens.
If your development situation has enough uncertainty that scrum is the better fit, you'll have less reliable metrics for planning, but a lot of flexibility to deal with the unexpected (which you expect to encounter with some frequency, otherwise you'd be using kanban).
Cutting edge technologies and startups are usually better suited to scrum because they need the flexibility to pivot when needed. Well established technologies (like Oracle DB or MS Office or Ubuntu or Jira or a CRUD app) are likely better suited to kanban because they'll benefit from the streamlining at the cost of flexibility they don't need anyway.