Setting the policy to DROP just means that clients will try multiple times before timing out, which means not only will you waste bandwidth with the retries, but your own clients will experience a delay while they time out instead of receiving an instant rejection.
For legacy IPv4 networks the address space is so congested and in short supply that it's economically unviable to leave unused addresses, so you gain nothing from this. With IPv6 there might be some very limited security-through-obscurity value to someone not being able to identify a live address, but its also not practical to scan sequential address space anyway.
What this article really highllghts however, is how flawed the perimeter security model is. Modern end user devices will actually do perfectly well on an open connection, as they don't have any externally visible services. Indeed people frequently connect their devices to public wifi networks where they are fully exposed to the network owner, other users and potentially beyond and it hasn't caused the apocalypse.
People are relying on the perimeter security model, and then using really lousy insecure devices to actually implement that perimeter so they get the worst possible outcome. User think their devices are inside a secured perimeter when the very device supposed to be enforcing that perimeter has been compromised putting the attacker inside. These devices are often MUCH worse than today's end user operating systems.
The proper solution is zero trust - assume your devices are fully exposed and have to stand alone.