Re: Remember, business people, there're telling you about it because they like you.
"This is a Board level issue. Someone saves you a $m+ hit from a hack a script kiddie could mount at any time and you want to hand them a f**king tee shirt? How about $100k instead?"
The answer is quite simply arrogance. Given the contempt that a lot of these companies have for their own customers, partners and staff, what makes anyone think that they'd have greater consideration for security researchers?
The size of the company doesn't matter either. Lots of SMBs - in my experience software developers are the worst for this - believe they simply know better than everyone else. Their vision is so pure, their execution so flawless and their designs so beyond reproach that anyone who questions them is not merely an affront to their genderhood, they are blashemers.
Consider, for example, Microsoft's approach to the Metro UI. Customers, partners, developers and staff who didn't like it were considered apostates and cast out. That same contemptuous arrogance resonates throughout the industry, ultimately resulting in a - to put things politely - "combative" relationship with security researchers.
It's also why in-house penetration testing and security research is so often left until repeated failures force the issue: the consideration is not merely one of money or "shareholder value". To accept that such things are required is an painful affront to the ego, self importance and exceptionalism of powerful alpha nerds that run the place.
It's easy to point to majors like Yahoo! and say "that t-shirt thing was board-level penny pinching", but even with a company that large it isn't that simple. The issue has to be raised with the board. Who is going to do that? The devs? For all the reasons above, that's unlikely. And once it is raised, what is the board going to do...probably talk to the devs and see if it is "really necessary".
This is why I think the BugCrowd guidelines are a great idea, and something sorely needed in our industry. They are an objective standard that you can present to a board. You can say "here is the best practice, regardless of what the alpha nerds say."
You will likely never convince the superprogramer owner/operator startups that this is required...but it should help convince companies like Yahoo in the future. Any company where the board isn't made up of alpha nerds with a personal investment in the code itself should be able to be convinced by something like the BugCrowd guidelines.
It's sad that we need stuff like this...but it is very human that we do.