Having the Gateway drop a device is only solving part of the problem, and arguably the smallest part. Basically any black listing scheme will only save the very small amount of server and backhaul processing involved, and as a LNS and ‘t Internet’ are both designed to operate at (massive!) scale the saving is relativey minor.
That is why I alway recommend nail the device/user if at all possible!
The GW will still have to ‘do its thing’ - as will ALL Gw’s in hearing range…on detection of pre-amble/signal the GW internals will kick into gear and schedulers allocate resources to route, store, process and subsequently decode the errant message. That consumes valuable GW resources and opens up an opportunity cost of not then having resources to handle co-incident messages. Only after decode will the GW then have sufficient data to make a black listing decision (Join EUI, Dev EUI or what ever), by which time GW has done 90% of what it would have to do anyhow…then it needs to run an exception/reject process…
Worst of all blacklisting does nothing to stop the waste of arguably the most precious resource of all - the RF spectrum and airtime/capacity and effective short duration increase in noise floor that is associated with the rogue device Tx’ing… Nah; best option find it and kill it (if possible) then everyone benefits: other RF spectrum users, owners of GW’s the full community and all GW’s in range and by extension you also get the backhaul comms and LNS load reduction win! 
It can be a pain tracking down but has the greatest return…