acer's comments are really thoughtful. I generally agree with them, even where they seem to contradict what I said; this can easily be explained: my own comments were a little too brief to appropriately deal with the true complexity of the situation in a number of cases (think of some of my comments as a caricature of the situation, based largely on truth, but also containing obvious inaccuracies, largely put there for effect).
I will only comment on a few points, where it seems valuable. If I don't comment, it is because I agree (including point #2 above where acer says I am being unfair to Mathematica!). In some places, I agree wholeheartedly, in particular his point #4.
Point #5: there are few tools for 'forgetting' because the modern way to remember (option Cache) handles this very well already.
Point #7: Mathematica seems to 'get' functional programming (which is what Reap and Sow really are, they are basic combinators from functional programming) better than Maple, which can't quite seem to shake its procedural heritage, even though it has seq/map and a few other similar primitives. If you teach people the 'right' primitives and downplay to procedural ones, better code would be written. It made a certain amount of sense (in 1980!) to have the Maple language be Algol/Pascal-like, since those were the prevalent ideas at the time. But in 2011, procedural is really no longer the prevalent paradigm; in fact, even OO is slowly declining. Functional and model-based are in high ascendancy. Maple is actually very well placed to 'play' in both of these arenas (unlike OO, where the few features that were added to Maple to make it more OO friendly luckily never really took off). Of course, MapleSim is as model-based as it gets (good!). In fact, and this is quite amusing to me, the underlying denotational semantics of MapleSim, as I learned recently, are relational rather than functional [think Prolog]. At the model-based level, this makes a lot of sense. At the 'programming' level, one generally wants more control (because of predictability).
The comment about "misplaced subservience to users' wishes for convenience" is very interesting. In my own work, I have been thinking about this very hard. A few of those thoughts have been published in the paper High Level Theories with Bill Farmer. (There are slides of talks, some by Bill, some by myself, which I should also put up which expand on this theme.) The basic idea is to create a layered system, with the lowest layers being 100% aimed at highly trained, expert developers, and the highest layer being 100% aimed at a non-programmer user, with intermediate layers serving as compromises in between. The error that acer points out is to pervert the low-level language for user convenience, as well as to pervert the user-interface with programming concepts. I do not believe that there exists a palatable compromise that serves both audiences well, so it is better to not try.
Regarding #9 (pattern matching): completely agree. The problem here is that there is a huge disconnect between the marketing of the feature and the reality of what you get when you program with it. Because the innards of how pattern-matching are not known or documented, it is impossible to predict how such programs will work. And it is very well known that pattern-matching based programs (in general, this is not specific to Mathematica, but is true of all term-rewriting) are extremely hard to control/predict/etc. And it does generalize to other areas where the actual cost of the routine (like unapply) is not well understood.
Regarging #10 and save on memory management time by producing less transient, collectible garbage: I would love to know how to do this. I currently don't really know how to do this. The theory that I know about this requires features (like 'let ... in ...' !) which Maple does not (yet?) have.