I'm pretty sure I wrote about the history of the Enterprise vs. Standard decision making on my blog (http://hal2020.com) but I can't find the post right now. I'm one of the people responsible for the original philosophy, and I don't think it's changed much. I'll go back and look for it again.

Basically you have three dynamics going on. The reality check of course is that the competition is Oracle and IBM DB2, and to a lesser extent open source databases, and various analytics products. Check out Oracle's price list and SQL Server Enterprise remains inexpensive. And Microsoft has introduced cheaper options to keep "free" open source options somewhat at bay, though the truth is that without multiplatform support there is nothing they can do to really capture that segment of the market.

Standard Edition exists because I couldn't convince my then boss that we should bifurcate it into a couple of sensible products, one slightly lower in capability and one slightly higher. The slightly higher one would have been a "Small Business Enterprise" edition that included many of the features of Enterprise but somehow retained differentiation from full Enterprise and would have been dramatically less expensive. I had a differentiation, but I don't recall what it was. The reason the bifurcation was rejected was that Standard was the edition that matched earlier versions and we didn't want to piss off customers by forcing them into a more expensive or less functional edition. And we didn't want to complicate the world with yet another two editions. So the status quo was maintained. BTW, this is a late 90s discussion.

The next dynamic is that there are a lot of features which cause a crapload to engineer but don't increase product volumes substantially. This is the primary driver of what becomes a candidate for Enterprise rather than Standard. When you are investing $10s of millions in a particular feature's engineering then you want some way to get a return on that investment. It really is that simple. Almost.

There is (or was) a re-analysis each version of what goes into each edition. My philosophy was that you introduce new enterprise features in the Enterprise Edition, then examine moving them into Standard Edition in subsequent releases. So there is a constant stream of new high-end features flowing into Enterprise, then as they become part of the mainstream thinking you push them (or appropriate subsets) into Standard. But that philosophy was never adopted and so the effort seems far more haphazard than I'd wanted it to be. Customer and competitive pressure will result in capabilities being pushed into Standard, but it doesn't seem to happen in a rational way.

Max memory size and high-availability features were the original differentiators when Enterprise Edition was introduced as a mid-life kicker for SQL Server 6.5. In the case of memory it was an actual technology differentiator back in the mid-90s on 32-bit machines. That it has survived through the 64-bit transition is shocking. But the reality check is likely that very few servers actually have more than 64GB,despite today's hardware prices, and thus Microsoft sees it as an acceptable differentiator. High Availability should remain a differentiator, though a simple subset does need to be in Standard. That the current subset is actually deprecated is, ummm, looney.

Customer demand for capabilities in editions other than Enterprise, or competitor moves, will lead to Microsoft changing the balance between Standard and Enterprise. But it isn't a few sophisticated DBAs/developers/etc. calling for the change. Or a niche or flash-in-the-plan competitor. It is an actual shift in market dynamics.