Right, but you can just do that with whens, and it's a lot clearer how the event is organized because each subconditional's trigger logic is kept local. With if-then-else (which I've used in massive pyramids) it's easy to get lost regarding how deep you are and exactly what logic is currently producing the responses you're working with.
The bigger my events have gotten the more importance I've found elegance, internal robustness, and local storage of information to be. You want as little as possible of your event to be scattered across the event, and if-then-else violates that rule by forcing you to keep track of how deep you've gone in the branching.
So for example we could take your example of picking a response using if then else:
IF: situation's good AND we hit 'time for this to happen'
SAY YAY!
ELSE - If: situation's okay
SAY OKAY
ELSE - If: situation's kinda bad
SAY KINDA BAD
ELSE - If: situation's real ****ty!
SAY KINDA ****TY
ELSE - cruiser's gone!
SAY CRUISER'S GONE
But with nested conditionals you can just use (and I'm going to write this in the worst case):
When: it's time for this to happen!
IF SIT'S GOOD but NOT OKAY, BAD, ****TY OR GONE! say it's GOOD!
IF SIT'S OKAY but NOT GOOD, BAD, ****TY OR GONE! say it's OKAY
IF SIT'S BAD but not GOOD, OKAY, ****TY OR GONE! say it's BAD!
IF SIT'S ****TY but not GOOD, OKAY, BAD, or GONE! say it's ****TY!
IF SIT'S GONE but not GOOD, OKAY, BAD, or ****TY! say it's GONE!
I think that's a lot more readable and a lot easier to spot errors in. It's also more robust if you want to alter something, and it looks nicer in FRED
(if we stick to your hull strength example this is even easier, since you just say
When: it's time for this to happen!
IF SIT'S GOOD say it's GOOD!
IF SIT'S OKAY say it's OKAY
IF SIT'S BAD say it's BAD!
IF SIT'S ****TY say it's ****TY!
IF SIT'S GONE say it's GONE!)