It's a side effect of deployment costs being tied into the same counter that is used to represent ship destruction and having 1 DP equal 1 supply used per deployment.
You can view CR as a storage tank of supplies. A Hyperion that can reach 100% CR means the tank can hold 37 supplies, since it can deploy 2.5 times or whatever before hitting zero. A Venture which can reach 100% CR has that tank capable of holding 100 supplies, and can deploy 10 times before hitting zero.
The system works fine and is an advantage as long as a ship doesn't encounter an event which hard sets the tank to zero, ignoring the number of supplies in the tank, as opposed to subtracting an amount in some way proportional to deployment costs from it. Specifically, destruction of a ship hard sets it to zero, ignoring the proportional number of supplies in the tank, and is where having a bigger tank becomes a disadvantage. Also being a long battle and running past your peak performance time (PPT) also can run your CR down to zero. Normal deployment of a ship within PPT is just using DP worth of supplies out of the tank, and so works fine. 37-15=22, and so just takes 15 supplies to top up again. 100-14=86, and just takes 14 supplies to top up a Venture again after a deployment.
Given the current system, the directions one could go to try to equalize this in some way are a bit limited. You could for instance make destruction only subtract two or three times the deployment cost. Although this might look a bit weird when a destroyed Onslaught is picked up with 52% CR. This is kind of what the Field Repairs skill does, giving all ships 30-40% CR and Hull after being salvaged, although it's still a fixed % rather than relative to deployment costs. You'd have to change Field Repairs in such a system.
Another option would be to let CR go negative, and instead of destruction setting to 0% CR, let it be something like subtracting 6 times deployment cost. Field repairs could restore 3 times deployment cost for free.
To handle the CR drop after PPT, you'd have to make the time between % of CR ticking down proportional.
Say it takes 4 seconds for 1% of CR to be lost after PPT. Change it now to be proportional to CR per deployment cost. Let's make 15% CR per deployment average and take 4 seconds to tick down 1%. 12% CR per deployment would tick down in 5 seconds, and 40% CR per deployment would tick down in 1.5 seconds. You'd essentially be consuming the supplies in your "tank" at a proportional rate.
Without a fairly significant mechanics overhaul, the only way to make that screen shot have roughly equal supplies costs to go from 0% to 70 or 100% is to set the % CR per deployment to be the same. So either Ventures need to cost 40% to deploy every time, or the Hyperion needs to only cost 10% per deployment, or some value in between like 15% for both.
As an aside, I'll note you currently pay the same flat rate in supplies per day if you are restoring CR, restoring hull/armor, or restoring both. If you're repairing the ship at all in any form, you simply pay DP * (recovery rate / CR per deployment) * d-mod discount per day. I think for most destroyed ships, the hull/armor restores in under the time it takes for the CR to reach maximum? Might not be true for Automated ships with low max CR though.
As for storm damage, I believe it subtracts supplies from the tank rather than picking a % CR to set to, unless the tank is not big enough, at which point it sets it to zero and stops. Quote from Alex on the matter:
Actually, here's a semi-related question. When hyperspace storms deal damage and reduce CR, is it proportional to the CR per deployment (i.e. a 10% CR per deployment ship takes half the CR hit from a storm that a 20% CR per deployment ship) or is it some kind of flat supply value or what?
IIRC, it's based on a target supply value worth of damage it wants to deal, though it won't always be able to do that, depending on the ship that's picked.
So you won't cruise through storms at 1/4 the cost in a high tech fleet, unless all your ships are getting set to 0% CR on the way and should have been set to -300% CR.