If the reflected packets are being sent to a closed UDP port, then the kernel on the receiving end is going to be generating an ICMP error message. This processing is quite cheap, so the processing time needed to process the UDP packet and send an ICMP error is likely to be the least of your concerns.

In some scenarios the upstream bandwidth consumed by the ICMP errors may be a real concern. In such scenarios, rate limit of the ICMP errors may be needed.

Silently dropping all the UDP packets without ever sending an ICMP error is however not advisable. The ICMP errors is the only signal the owners of the involved DNS servers have, that could tell them, that their DNS server is involved in a reflection attack. In other words, by silently dropping the packets, you are hiding the attack from the very people, who could mitigate it.

It is technically possible to design a DNS server with automatic mitigation of reflection attacks. However such mitigation would have to rely on ICMP error messages. If such mitigation methods become widespread, you would make yourself an easier target for A DDoS attack by silently dropping all attack traffic.

If the reflected UDP packets would be arriving at an open UDP port, then processing those reflected packets would become more expensive in terms of CPU time. In such scenarios it would be advisable to use iptables rules to REJECT packets whose source port is 53 or any other used by services commonly abused in reflection attacks and whose destination port is that of the service you are running. I would still not DROP them, but rather use the REJECT target to produce an ICMP error identical to what is seen on a closed port.