That would be nice, and I thought about that myself, but I also don't currently have the time to set that up, since I expect that would involve a lot of work to do the hit tests/stat array search at a reasonable speed.
EDIT: on second thought, there is an O(1) way to do this, at least for the selected player (O(n) for any player): Since the values are stored in an array that gets entries with a fixed time interval between them, you could take the mouse x coordinate relative to the graph, divide by width (to get a value between 0 and 1), multiply by the number of entries in the array used to populate the graph to get an index and a fractional part. Use the index and the index + 1 to get the two bounds of the desired point, and interpolate between them with the fractional part to get the value of the graph at the given time/mouse x coord.
It's a bit involved, but it should scale optimally with graph length/game time.
If it isn't limited to the selected player, then you'd have to do this for every line, and compare the resulting values with the mouse y coordinate to find the nearest one, which becomes a possible dev time sink if we want it to scale better than linearly with number of players, but it would only be doing at most 30 or 40 comparisons every time the user moves the mouse (average case would be 2 or 3 if we order the lines by y value and do the same trick as the x-axis thing above and ditch early once y values get further away from the mouse than what we've currently found, though ordering the lines by y value would be the tricky part optimization-wise), so that's not the worst performance loss
