You're implying that APL is complicated. It isn't. It was designed for regularity and simplicity. Iverson and his group worked on that for 7 or 8 years (can you imagine!) before they began implementing it, and what they came up with remains one of the great high water marks of software design.
This brings out a problem with the OP and the discussion. We readily dismiss things as complicated that are merely unfamiliar. The converse is also true: we don't see complexity once we've become habituated to it. And we become habituated surprisingly quickly.
So how do we distinguish between complexity and unfamiliarity? Without some reliable distinction, this is all in the eye of the beholder.
I think you're throwing out the baby with the bath water. The fact that unfamiliarity can be mistaken for complexity does not mean that complexity is impossible to recognize or avoid.
There are some cases where you can, for example, radically simplify a complex algorithm by using an unfamiliar toolkit (Feynman diagrams, Lisp, etc.) but there are also cases where a solution is obviously more complex than it needs to be even within its existing framework.
Oh, I don't claim that complexity is impossible to recognize. It's really important to do so. But how?
Most judgments of complexity we currently make have a lot to do with familiarity. (Is the 40-line spreadsheet program at http://www.nsl.com/k/s/s.k complicated or simple?) You assume something similar when you say "obviously more complex than it needs to be". When is complexity obvious? When it exceeds what we habitually consider ok.
What we really need is an objective measurement. Do we have one? We sort of do, insofar as the research on this seems to point in one direction: shorter programs are simpler. That doesn't answer every question - you still need a way of measuring program length and defining what a program is - but it's the beginning of an objective answer.
For evaluating a refactoring or using a library/framework, you can compare the number of statements that would be used to add a given feature before vs. after the refactoring.
What's harder is to evaluate the effect of adopting a certain pattern or framework will have on the cost of future refactorings. I don't think people do even a back of the envelope estimation of even just the first number. The number of statements put in can probably be used to estimate the cost in man hours.
My preference would be to put it in when it pays for itself (i.e. makes the code smaller) and not before. Otherwise it's too easy to fall victim to one's own spin.
Good point. There are multiple axises of difficulty. Amount of things to remember, interconnectedness of said things, potential drawbacks, unfamiliarity, idioms etc.
This brings out a problem with the OP and the discussion. We readily dismiss things as complicated that are merely unfamiliar. The converse is also true: we don't see complexity once we've become habituated to it. And we become habituated surprisingly quickly.
So how do we distinguish between complexity and unfamiliarity? Without some reliable distinction, this is all in the eye of the beholder.