Of course you could say something in standup about it, but you and I both know you'd probably be gently admonished for wasting time on it and asked to go back to what you were doing. because ... sprint goals, quarterly objectives yada yada yada.
If you make doing this enough of a habit, it might show up in your one on ones and evaluations even. There goes your big annual raise.
In essence, you have to do your work AND go figure out these sorts of things on your own time. Thats how you find yourself putting in 50-60 hour weeks, but its okay because you're a "passionate" engineer.
Either way The business wins.
As for how to account for that work in your velocity, I don't believe it is realistic to size a story for fixing a potential issue (not to mention the difficulties in sizing bugs anyway [1]). However, it is possible (or at least a bit easier) to size a story for research that answers a specific question as its acceptance criteria -- in this case, the acceptance criteria for this article's situation would've been something like 1) "will latency continue to rise?" and 2) if so and it is unacceptable, what is the cause and add an implementation story to the backlog"
Some may say "well, how do you know how what is causing the issue", and if no one really can figure it out the answer to the research story question and the bug has manifested itself as an emergency, then sure your velocity will tank as you break the sprint(s), but it's up to the team/business to understand how to remove outliers for an accurate velocity.
[1]: http://www.agileforall.com/2010/05/agile-antipattern-sizing-...
It's worth noting that I agree with your point and also don't believe Scrum is a panacea, but I am starting to understand its appeal from a business perspective.
Velocity shouldn't be used to measure how "good" the team is.