The Short Answer
The short answer is: "So you don't get hit with a $5 million class-action lawsuit." That should be reason enough for most CEOs. Hashing passwords is a lot cheaper.
But more importantly: simply hashing the passwords as you suggested in your question isn't sufficient. You'll still get the lawsuit. You need to do more.
Why you need to do more takes a bit longer to explain. So let's take the long route for a moment so that you understand what you're explaining, and then we'll circle around for your 5-minute synopsis.
Hashing is just the beginning
But let's start with that. Say you store your users' passwords like this:
Now, let's say an attacker manages to get more access to your system than you'd like. He's only there for 35 seconds before you detect the issue and close the hole. But in those 35 seconds he managed to snag your password database. Yes, you made a security mistake, but you've fixed it now. You patched the hole, fixed the code, updated your firewall, whatever it may be. So everything is good, now, right?
Well, no, he has your password database.
That means that he can now impersonate every user on your system. Your system's security is destroyed. The only way to recover is to start over with NEW password database, forcing everyone to change their password without using their existing password as a valid form of identification. You have to contact them out-of-band through some other method (phone, email, or something) to verify their identity to re-create their passwords, and in the mean time, your whole operation is dead in the water.
And what if you didn't see him steal the password database? In retrospect, it's quite unlikely that you would actually see it happen. The way you probably find out is by noticing unusual activity on multiple users' accounts. Perhaps for months it's as if your system has no security at all and you can't figure out why. This could ruin your business.
So we hash
Instead of storing the password, we store a hash of the password. Your database now looks like this:
Now the only thing you store is an opaque token that can be used to verify whether a password is correct, but can't be used to retrieve the correct password.
Well, almost. Google those hashes, I dare you.
So now we've progressed to 1970's technology. Congratulations. We can do better.
So we salt
I spent a long time answering the question as to why to salt hashes, including examples and demonstrations of how this works in the real world. I won't re-hash the hashing discussion here, so go ahead and read the original:
Why are salted hashes more secure?
Pretty fun, eh? OK, so now we know that we have to salt our hashes or we might as well have never hashed the passwords to begin with. Now we're up to 1990's technology. We can still do better.
So we iterate
You noticed that bit at the bottom of the answer I linked above, right? The bit about bcrypt and PBKDF2? Yeah, it turns out that's really important. With the speed at which hardware can do hashing calculations today (thank you, bitcoin!), an attacker with off-the-shelf hardware can blow through your whole salted, hashed password file in a matter of hours, calculating billions or even trillions of hashes per second. You've got to slow them down.
The easiest way to slow them down is to just make them do more work. Instead of calculating one hash to check a password, you have to calculate 1000. Or 100,000. Or whatever number suits your fancy. You can also use scrypt ("ess-crypt"), which not only requires a lot of CPU power, but also a lot of RAM to do the calculation, making the dedicated hardware I linked above largely useless.
This is the current state-of-the-art. Congratulations and welcome to today's technology.
Are we done?
So now what happens when the attacker grabs your password file. Well, now he can pound away at it offline instead of making online guess attempts against your service. Sadly, a fair chunk of your users (4% to 12%) will have used the password "123456" or "password" unless you actively prevent them from doing so, and the attacker will try guessing these first.
If you want to keep users safe, don't let them use "password" as their password. Or any of the other top 500, for that matter. There's software out there to make accurate password strength calculation easy (and free).
But also, multi-factor authentication is never a bad call. It's easy for you to add to any project. So you might as well.
Now, Your 5 Minutes of Glory
You're in front of your boss, he asks you why you need to use PBKDF2 or similar to hash your passwords. You mention the LinkedIn class-action suit and say, "This is the minimum level of security legally expected in the industry. Anything less is literally negligence." This should take much less than 5 minutes, and if your boss isn't convinced, then he wasn't listening.
But you could go on: "The cost of implementing hashing technology is negligible, while the cost of not implementing it could be in the millions or higher." and "In the event of a breach, a properly-hashed database allows you to position yourself as a well-run security-aware organization, while a database improperly hashed is a very public embarrassment that, as history has shown many times over, will not be ignored or overlooked in the slightest by the media."
If you want to get technical, you can re-hash the above. But if you're talking to your boss, then you should know better than that. And analogies are much less effective than just showing the real-life effects that are perfectly visible with no sugar-coating necessary.
You don't get people to wear safety gloves by recounting a good analogy. Instead you put some lunch meat in the beaker and when it explodes in green and blue flames you say, "that's what will happen to your finger."
Use the same principle here.