So, with a REST connection, the client makes a connection, sends a request, gets a response, closes the connection. You might have 1000 "simultaneous users" but at any one time that might mean only 100 actual connections in progress.
With WebSockets the connection is opened, then held open. So 1000 users means 1000 connections. So this is a limitation in the sense that there will be a max number of connections your OS can handle, and as the connection pool gets large there is some overhead in managing that connection list.
There will be some minor traffic to each connection (Ping/Pong) every minute or so to keep the connection open.
Websockets perform better because the connection is already open. So the client can push data quickly with no overhead. Equally the server can push data at the client which it can't do in a REST situation. Depending on your requirements WebSockets may be less actual network traffic because there are no polling REST clients "just checking for new info".
In most API situations REST is perfectly sufficient, and programmers are familiar with it, so it's easy to default to that. In most API situations data changes infrequently, and does not require immediate update. Games are different because data changes _very_ fast (depending on the game) and of course in most cases requires immediate update.
For your situation (with the data you provided) there's no absolutely right answer, but if the game is multi-player and real-time, then sockets are likely to be a good option.