in reply to $bad_names eq $bad_design

I agree with the premise: but sometimes the problem isn't actually the design: its that you're trying to abstract something too far.

Consider your example:

# if we have an expense account and the amount is too large if (4223 == $acct and $amount >= 100) {
which became
if ( excessive_expense_account($acct,$amount) ) {
If I don't understand the system, then the second form is probably no better than the first. Although the named function is explicit, I still need to look at the definition because I don't know what an excessive_expense_account is. A better name might help (e.g. "expense_account_is_over_limit(...)"): but, as a maintenance programmer, I'd prefer to see:
if ( $acct->is_expense_account && $amount > EXPENSE_LIMIT) {
This contains meaningful names, which helps me to read the code: plus it has detail, which is needed for me to truely grok it. When we abstract out the detail, even to a meaningful name, then we circumvent the human brain's chunking mechanism. We only have a meaningful name: not the detail that enables the brain to see the patterns.

The summary: don't abstract too far. If you have difficulty finding a name, then by all means use this as a flag to re-examine the design. But if the design look good, then consider leaving it alone: don't force details into function names. Polysynthetic identifier names are all very well, but grammar exists for a reason: to aid comprehension.