Attack scenario
1st phase is to find IP addresses of the delegates if they are not known:
1. Connect to as many nodes as possible.
2. Memorize time moments when nodes share a new block.
3. Analyze block travel graph trying to find its origin.
2nd phase is to check if anti-spam is used:
1. Prepare a list of already confirmed transactions.
2. Feed our own node with as many transactions as possible measuring CPU usage (signature validation, double-spending prevention, etc. require a lot of CPU cycles).
3rd phase is to disrupt unconfirmed transactions processing (if there is no anti-spam):
1. Feed the next delegate with as many transactions as possible.
2. Check if the generated block contains only a fraction of pending unconfirmed transactions.
This attack is easily counteracted with Hashcash-like spam prevention. If there is no anti-spam or it's not effective enough then the attack should be extended to DoS all delegates one by one.
So, what are odds that the attack will succeed to noticeable slow down inclusion of transactions into blocks?
Delegates can easily avoid this by using relays in such a way that the delegate is connected only to relays. Relays will not forward invalid or duplicate transactions.
Valid transactions are OK provided they have sufficient trx fee. It is OK to flood the network with transactions. You'll pay the price.
However your method will reliably filter out unprepared delegates. That is a good exercise I was meaning to do for a long time.