contextgrid-typesettingluatextypography
As I understand, the problem with the grid typesetting lies in the mechanism TeX uses for page construction. There are a few packages that try to fix that and that may be done (hopefully) with LaTeX3.
My question is why the mechanics used in ConTeXt cannot be used in LaTeX, and what made grid typesetting in ConTeXt possible.
As you have noted, ex (and em) lengths are relative to the currently used fonts. The reason for this depends on the application. In your instance it makes sense using a font size-specific length, since the typesetting the sectional heading may be different depending on whether the document is processed using 10pt, 11pt or 12pt (or, for that matter, any other font size) as \normalfont. For example, using absolute lengths (like pt, bp or pc, for example) may cause the gap between section headings and text to seem too small, or too large, if the font size is changed. The example below a font-based skip of 1em between a pseudo-section heading is replaced by a fixed-width 11.5pt skip (in 10pt, 1em or roughly 11.5pt, see the TeX Book, p 60):
\documentclass{article}
\begin{document}
\bfseries% For bold font
{\normalfont Font-based skip of \verb!1em!} \par \medskip
\newcommand{\myskip}{\unskip\rule[0.5ex]{1em}{1pt}\ignorespaces}
{\normalsize 1 \myskip A section \par}%
{\large 1 \myskip A section \par}%
{\Large 1 \myskip A section \par}%
{\LARGE 1 \myskip A section \par}%
{\Huge 1 \myskip A section \par}%
\bigskip \hrulefill \bigskip
{\normalfont Fixed-width skip of \verb!11.5pt!} \par \medskip
\renewcommand{\myskip}{\unskip\rule[0.5ex]{11.5pt}{1pt}\ignorespaces}
{\normalsize 1 \myskip A section \par}%
{\large 1 \myskip A section \par}%
{\Large 1 \myskip A section \par}%
{\LARGE 1 \myskip A section \par}%
{\Huge 1 \myskip A section \par}%
\end{document}
Since I am not entirely sure of your sectional intent (that almost came out wrong), here's a suggestion when it comes to page-breaking woes. The needspace package provides \needspace{<len>} that issues a \break if there is less than <len> space available on the page. And, the code is not very complicated. Here is a modified version, now taking 3 arguments for the sake of this discussion:
\makeatletter
% \needspace{<len>}{<NOT enough space>}{<enough space>}
\newcommand{\needspace}[3]{\par \penalty-100\begingroup
\setlength{\dimen@}{#1}%
\dimen@ii\pagegoal \advance\dimen@ii-\pagetotal
\ifdim \dimen@>\dimen@ii% execute the following if there IS NOT enough space on page
\ifdim \dimen@ii>\z@
\vfil
\fi
\break
#2% <NOT enough space>
\else% execute the following if there IS enough space on page
#3% <enough space>
\fi\endgroup}
\makeatother
It would be possible to redefine \section so as to use the above \needspace and condition on the type of \@startsection that should be called.
A full answer here has several parts. First, at the time of writing it's important to bear in mind that ConTeXt is not only available but works well, while LaTeX3 is a concept which is being developed. That means that it's not even 100% clear what shape LaTeX3 will take. It's also not clear that LaTeX3 will deliver, but for the purposes of answering the question I'll ignore this! I'll also highlight what seem to be (broad) similarities.
There are then two broad areas to talk about: the user 'experience' and the implementation. In both areas, there are differences but I'd like to highlight one important similarity: both ConTeXt and LaTeX3 are ultimately TeX-based. A radically-different approach from either would be to parse input using another language (Python is often highlighted, for its scripting ability), then convert to TeX primitives (plus low-level macros), and only do the real typesetting in TeX. Neither ConTeXt nor LaTeX3 do that.
At the user level, LaTeX works with the concept of a document class as a key concept, .i.e. you always have:
\documentclass{<whatever>}
In LaTeX2e, the separation between a class and adding code is somewhat diffuse. The idea for LaTeX3 is to make 'design' and 'code' separate areas, and so have the document class as a purely design concept. ConTeXt does not enforce the idea of a loading a particular 'style' for a document in the same way (although it is possible to load a module to set defaults). There is a key philosophical difference here, as ConTeXt is in many ways closer to the plain TeX concept of 'author as designer', while LaTeX3 is intended to enhance the separation of the two roles.
An area where there is clear similarity is that LaTeX3 will make a lot more use of keyval input 'out of the box' than LaTeX2e does. This is very much a similarity to ConTeXt, which makes extensive use of keyval. There are, however, differences in implementation (the classic one is that LaTeX keyval input skips spaces around the =, while ConTeXt does not).
Another similarity in this area is that the scope of 'core' LaTeX3 supported ideas is intended to be much broader than 'core' LaTeX2e ones, and thus similar to what ConTeXt manages. Quite how this works out depends on the development of LaTeX3, do it is not possible at this stage to give a more detailed analysis of this area. This area encompasses the 'limitations of LaTeX2e' part of the question. For example, ConTeXt can do proper grid typesetting, which is a significant challenge in LaTeX2e.
At the implementation level, ConTeXt (Mark IV) uses a mix of TeX and Lua. On the other hand, LaTeX3 is (currently) dependent on e-TeX plus the \pdfstrcmp macro (or equivalent functionality), and thus works with suitably recent versions of pdfTeX, XeTeX and LuaTeX. LaTeX3 then constructs a programming language of its own ('expl3') using the require TeX primitives. This is clearly a fundamental different, as Lua provides ConTeXt with a flexible programming system and also access to TeX internals that are not available using primitives. At the time of writing, it's not clear how LaTeX3 might handle 'LuaTeX-only' ideas: might there be team-supported 'LuaTeX-only' modules, for example?
The fact that LaTeX3 uses only TeX, whereas ConTeXt uses a large amount of Lua, leads on to the fact that LaTeX3, like LaTeX2e, is intended to be a TeX format which can be used in a 'classical' manner
pdftex "&latex3" <myfile>
ConTeXt, in contrast, is a more 'dynamic' assembly as the Lua part is not saved into the format file. Thus ConTeXt is always executed using the context script. Using this script-based wrapper, ConTeXt can deal with multiple TeX runs, indexing and so forth 'automagically'. The intention (at present) is that LaTeX3 will work in the same way as LaTeX2e: one LaTeX run = one TeX run.
ConTeXt is build explicitly on TeX and Lua, while LaTeX3 defines its own language, expl3. Thus programming ConTeXt means programming in TeX, which is not documented formally in the ConTeXt manuals. A key driver behind LaTeX3 is the idea that beyond the kernel, everything needed to program LaTeX3 should be documented in the LaTeX3 documentation.
LaTeX3 is also aiming for a clear separation between user functions and internal functions, i.e. for every document-level function \foo there should be a (documented) internal function \int_foo. ConTeXt has a very rich set of interfaces, but is not (to my knowledge) built on quite such strict 'two-layer' principles.
Best Answer
The key ingredient to grid typesetting is making sure that a line will end up at a fixed vertical position on the page, independent of content before or after.
In LaTeX this is not realised because the vertical glue inserted after equations or figures is always the same and does not adapt itself to the height of the equation or figure. The problem with this is that basically everything can break the grid. For example if you implement the adaptive glue for equations and figures but forget it for tables, those will mess with your vertical spacing again. There are some LaTeX packages which attempt to perform this task but they only work in a very limited range of the highly heterogeneous universe of documentclasses and packages.
ConTeXt on the other hand is very monolithic apart from very few third-party modules. This allows for a fully consistent implementation of the adaptive vertical glue and makes it kind of hard for the user to break this mechanism as long as high-level ConTeXt macros are used consistently.
The reason why that is not available for LaTeX has been partly laid out above already (heterogeneous environment, modular approach). Another point is that in ConTeXt MKIV the grid snapping is implemented in Lua and even if it was possible to port this to LaTeX, the resulting functionality would be limited to users of LuaTeX.
Finally a little example of grid typesetting in ConTeXt: