So, you just have one client machine polling or many? You really have two issues:
1) Reduce bandwidth usage
2) Optimize the selection process
For #1 (assuming only one client polling) I don't think you'll get much return by moving to an event model, possibly even worse depending on what mechanism you build. Right now its one query every 30 secs, may or may not return data. Doing it a different way might just generate MORE trips from server to client, though you would save the client to server request. But really, how much traffic is that?? A simple hack would be to just increase the polling interval. Do you really need to poll every 30 seconds?
On #2, putting a trigger on the table that will identify records that need to be processed and adding them to a "queue" table will speed up the select a lot. Once you process a record from the queue, remove it. Why cant you create a unique key? You can't add an identity or uniqueidentifier to it? Even if the app is generating its insert from the schema directly but is too dumb to understand what identity is, rename the table and create a view with the original table name.
A combo of my suggestions for 1 and 2 will probably net you some performance gain. You can eliminate network traffic altogether if you put the client app on the server. Perfectly valid solution in some cases - if the server has the capacity.