Flexibility is good. I agree with that approach. But then I fail to see the benefit in scrum in the first place. The other things you mentioned (measuring all these metrics) does not seem helpful to me at all.
When you can measure metrics with some reliability, your executive team can use those metrics to plan out releases (e.g. "the new Fizzbuzz feature is expected in Q3"). That allows your marketing team, budgeting team, and deal flow team to plan around it (with the understanding that it is statistically reliable, not necessarily individually reliable).
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.
