The main issue is that the Rhino programmers are not full-time Rhino modelers, thus they don’t experience various modeling challenges and the need to improve current tools and add new functionality in the same way actual modelers do. Here is an example of a real use case where the “Match surface” is incapable to properly match two simple surfaces of the same degree and control point count with a tangency less than 1 degree"
The same topic also consists a few more examples of real use cases that show the major weaknesses of the current “Match surface” tool in comparison to the similar tool in Alias (they call it “Align” instead) and other programs. The requests for those and many other improvements were repeatedly posted in this forum by many full-time good Rhino modelers for years, yet the actual improvements are scarce since Rhino 3 or Rhino 4. If I recall correctly, the “Match surface” in Rhino 4 was even downgraded by removing the “Refine match” option.
The other problem comes from the fact that when Rhino modelers experience questionable results while using some of the existing tools, naturally they don’t find it practical to use them in the future, because they are aware about the inability of the said tools to do the job. Then, the Rhino developers collect data that certain tools are not used often and they start to think that Rhino users don’t need improvements in those tools. It’s a never ending loop. A great tool with all the features that does the job properly will be used more often, whereas a half-finished tool with lacking features will be less used. That’s the reality. 
The lack of proper modeling tools also forces the majority of Rhino users to use bad modeling techniques, because they get frustrated by the limitations and inability to achieve a certain result while trying to use proper techniques.
The “RefitTrim” tool is a good example of such existing-but-not-optimized tool that people would love to use, but many try to avoid due to its shortcomings. While it helps in certain situations, in the majority of time it produces vastly different border shape that’s not related to the split edge that it tries to replace. I had multiple cases where splitting a surface with another FLAT surface and then applying “RefitTrim” to the split edge causes it to become CURVED and far from the natural flat border that a proper “RefitTrim” should do. Due to those inaccurate results, I rarely use “RefitTrim” and instead prefer to extract the border curves, rebuild them and then use the ! _EdgeSrf command, which usually gives me a far better approximation of the desired shape.
Another example is with the current “Blend surface” tool which is incapable of using the same U or V direction while matching to a single trimmed surface edge. Check the 2nd post here:
The issue in this particular case is that a single surface blend end uses TWO different directions (both, U and V) to match to a single trimmed edge, thus making the resulting blend surface unusable and forcing me to avoid the “Blend surface” tool for such cases. Then, Rhino developers may start to think: “Well, Bobi does not use the Blend surface as much, so probably it’s not important and we should not devote time into improving this particular tool since he uses alternative tools more often”. 
Also, “Blend surface” lacks an option to match the end handles in the same direction as the target surface’s side edges to achieve a natural G2 flow.