One way to increase that "expected gain" is to take a slightly wider view of what security is. Security is more than just locks and passwords - it includes defense against denial of service attacks, for example. A useful definition of system security is:
A secure system is one that continues to work properly, even in the face of attack.
An example is one of the most common security issues, SQL injection. My work place had a typical example:
INSERT INTO users SET fname='$fname', lname='$lname';
From a traditional security perspective, we worry about an attacker entering a "name" that includes quotes marks and such. However, the same issue also meant that things broke nicely when Tom O'Reilly tried to register, using his real name.
Fixing that issue meant that attackers couldn't mess up the system - and the "random" errors in the system stopped.
As another example, we provide a service called Clonebox. With Clonebox, if a customer's web server is hacked or otherwise damaged, we can switch it over to a ~read-only mirror. Sure that protects against hackers, and some customers have been hacked and used the protection. More often, customers simply screw up and delete important files or databases. Either way, they are protected - our customers' web sites keep working, even when they screw up, even when hardware fails, and even when they are hacked.
So the pitch, and the cost/benefit calculation is this:
How much is it worth to have systems that just keep working, that don't screw up, that handle any input gracefully?
It can be good to ask that question right around the time some executives are cursing the current system.