I know this topic started with frustrating crashes in Mathematica 10. I hope it is all right if I extend it to matters of ease of use in writing technical documents and applications. I think this is another area where WRI has either failed to sufficiently complete the task or veered off course. What WRI has done in terms of basics is so fantastic that the frustration is that it's not easier and more intuitive to put the pieces together in new and more precise ways. I'm not thinking of the more "primitive" routines as being access to low level code such as C++. Neither do I think of them as routines only for advanced users. I think they would be commonly used. And I recognize that there are some really hairy advanced algebraic algorithms that are not going to be broken into usable primitive pieces. Nor is there anything wrong with having high level routines for very common operations such as some common plots - as long as there is an alternative path. The problem comes when a user is encouraged to start with a high level construction and then modify it, usually through options, to a particular form that he may need. Sometimes this leads to a long set of trial and errors, which ultimately fail. This is a serious hurdle to what by rights should be a more common use of Mathematica. And, again, I would like to stress that WRI has created a great set of tools but they can in no way envision all the ways these tools could be assembled to study, investigate and present information.
Here are some examples. (Some of them I have attempted to address in my Presentations Application. All of them come from studying various mathematical topics and writing tutorial notebooks as a method of learning. Trying to design new "presentations" of established material is a good way of learning and can even be 'value added'.)
1) Why isn't doing graphics more like drawing on a piece of paper. If 'everything is an expression' is a central paradigm of the Wolfram Language, then why isn't 'everything is a graphics primitive' a central paradigm of graphics? Why couldn't curves, surfaces, trees, axes, bars, scales and various types of labels also be primitives like Lines, Circles, Points etc. You could directly generate them, operate on them if you wanted and put them where you want. Writing a really nice graphic usually involves a fair amount of detailed specification, with development and reevaluation. You want to be left with a detailed written specification (after all, you may want to add an extra curve, or some other item, or take out something later.) Something like Drawing Tools is not really satisfactory for this.
2) Custom tables are just as important as custom graphics. How many users find it easy to create custom tables? Are they used much at all? The problem here is that much of the specification is done with rather opaque Grid options. Why can't you draw a table like you draw a graphic?
3) Manipulate is the high level routine for dynamic displays. But again it makes many choices for you and is somewhat opaque with much use of options. Most dynamic displays would benefit from well designed placement of graphics, controls, text and digital display of values. The controls might not all be on the top or bottom or together. This is much easier to do directly, and more primitively, with a DynamicModule. You can include routines that calculate dependent dynamic values that may link various parts of the dynamic, and you can use Rows and Columns to lay out the display. Sometimes you might want to have a control as part of a graphic. Although a Control is usually a graphic it can only be inserted into a graphic with Inset. However, a control, such as a Gauge or Slider, comes with unspecified "stuff around it" and it is trial and error to precisely align it with elements of a graphic, and then it is not stable with respect to changes in the ImageSize of the graphic. I did end up designing some graphical sliders. Would it be possible for users to more easily design their own graphical Controls instead of just being given a palette of them to choose from?
4) Matrix reduction and manipulation is another area where more and better primitive routines could be provided. How about all the students who are learning basic methods of combining rows, pivots and things like that? There is a RowReduce routine that has one weakness. Suppose you wanted to confine the operation to a specific block of a matrix? (Don't reduce beyond that block but of course operate on all columns.) You can't do that. You might have a matrix structure with left and right hand sides and not want to extend the reduction into the right hand side.
I'm sure there are many other examples. I would prefer that WRI didn't try to write "convenient" routines for various fields. I don't think they are really good at it. The applicable applications are too many and their proper handling is too detailed. I don't know if they have time for that. What they can do is ferret out the basic operations and routines that are used in putting together mathematics and present them in such a way that it is easy and even intuitive for users. They are very good at the basics (and some of the basics are quite sophisticated). Let users have more control in putting them together.
Ii think the overall WRI documentation is very good. The one weakness might be in the content of some of the Function pages. Sometimes the examples are formalistic without enough practical examples that could be useful to students. It might be helpful if WRI had a mechanism (devoted to the documentation) where users could suggest improvements in a help page and sometimes even provide some practical examples. Over time this could provide a much richer documentation.
George Woodrow commented on Option completion. Presentations does have an OptionFinder feature that was contributed by Thomas Münch and Syd Geraghty. You can click in the head of a routine and then use the OptionFinder to display all the options for that routine. You can paste them in directly and change their values. It also has links to the help pages of all of the options and to the routine itself. I find this very useful.