You lack long-term vision, I assure you that BSGS with a sufficiently large database in the future, would double your current speed with Kangaroo, and to surpass it you would have to double your computing power, on the contrary BSGS would only have to store more keys, this is the interesting point of this research, which is not limited to how much computing power you have, and I'm not saying that Kangaroo is not efficient, I'm just saying that it depends on the net computing power, which is already beginning to be seen as a stone in the shoe.
You might as well be right. I started this off-topic with <Space x Time> is a constant, so obviously if you use a ton of "space" then you need less "time" to solve the same problem.
This is valid no matter what algorithm you use. So I got it now - you want to store lots and lots of keys, in less space, maybe so more keys fit is fast memory (RAM?).
The fallacy in your logic is however this one: you are thinking only in terms of a system that actually uses memory in a fast way, and comparing two algorithms on this same system. In this case, the one that trades off more memory for less time is BSGS. I wish you good luck with that.
However, if we start comparing BSGS vs Kangaroo on a system that trades off slow/no memory with
a lot more computing power, then what you find is that BSGS does not even apply, and an algorithm that is based on computing power alone, will always outperform it, simply because the amount of extra computing far surpasses any level of storage you optimized for, on a system with a low amount of computing power.