"does not seem to put a heavy load on MySQL"
For some number of users it must eventually put on a "heavy" load, but that's not a "bad thing".
For any application, architected in any way, there will be some point at which some part of the infrastructure creaks. That's not an intrinsic reason to adopt some more sophisticated solution (and move the bottleneck elsewhere).
So gather some empirical data, such as : for what number number of uses does this polling load become significant? Do some load tests, not just of polling but of the other work these users are doing. They surely are not just polling they are doing other stuff that will also load MySQL. When does this creak? At that point would the resulting revenues allow you to buy more capacity? Or would you have confidence that a different architecture would fix the problem. In other words do you have a realistic "out"?
My guess is that if polling becomes an issue you have some good intermediate solutions such as caching, or reducing the polling frequency, in addition to the possibility of introducing Comet. And so it's reasonable to start with your simple polling strategy.