There are elements of history and philosophy here. LaTeX was first written by Leslie Lamport to provide a 'user' interface to TeX that abstracted away some of the 'bare metal' of the typesetting. Lamport handed over the the current team in the late 1980s, by which time LaTeX was already popular in some academic circles. The integration of ideas from AMS-TeX into amsmath, and the (N)FSS font selection scheme, both occurred in the mid-to-late 1990s. These developments helped LaTeX to attract a significant audience in academia. It also means that 'LaTeX' ~ 'TeX' is used as a way to describe math mode markup well outside typesetting, e.g. MathJaX.
ConTeXt is as the question states also the original product of one person, here Hans Hagen. Hans started with in some ways less desire to abstract from TeX. For example, ConTeXt does not try to have any 'required' approach to defining document design, in contrast to LaTeX's document class concept. ConTeXt also started with a much richer interface setup, of course at the time with performance implications: these are no longer anything to worry about. ConTeXt was first developed long after LaTeX, and has not had significant take-up for academic publications.
LaTeX has attracted a large number of third-part package authors. In part this is arguably as the kernel was and still is very small in terms of functionality. ConTeXt by contrast has a lot of modules written by Hans and others at Pragma, but relatively few third-party extensions.
The two formats have historically different approaches to stability. Whilst LaTeX does change, there is a lot of work done by the team to try to keep existing documents unchanged. Also, the large number of third-party packages means that there are (internal) interfaces that are very difficult to adjust. This means there is a tendencies to avoid change, or at least to manage it very carefully. ConTeXt, with a small team responsible for most of the code, can be freer in terms of change. At the same time, ConTeXt users do know that the core is in active development and can require more active document management. That is not to say that ConTeXt deliberately breaks documents - the basic syntax for ConTeXt is the same in Mark II, Mark IV and Mark XL. But for example ConTeXt has moved from pdfTeX to LuaTeX to LuaMetaTeX, and that means that a user who used some primitives directly in their source will have had to update it: a LaTeX user might complain loudly if the same happened to them.
The LaTeX team had a rather fallow period in terms of kernel development for various reasons. One was that after the launch of LaTeX2e, the thinking was to freeze the kernel code entirely (for stability), and to aim to write a new LaTeX ('LaTeX3') to address long term desires. However, the large number of both users and particularly packages makes that a very challenging proposition. There is no doubt that ideas developed in ConTeXt over that period could and should be picked up by LaTeX: one can only though work on the situation now, not what hindsight suggests. (The LaTeX team had for example something a bit like CSS before CSS was invented, but it was not workable when developed and now has to work in a world that does have CSS.)
Work by the LaTeX team at present is focussed on adding things like tagging, which as the question notes is achievable using ConTeXt today. The constraint for LaTeX is of course in a sense self-imposed: that users do not have to update their documents at all. There is also the question of detailed engine outcomes. ConTeXt uses LuaMetaTeX, which like LuaTeX deliberately breaks some outcomes predictable for TeX90/pdfTeX/XeTeX/... For example, hyphenation is not tied to font, which may change line breaking and therefore typeset output. Similarly, using 8-bit fonts is non-trivial with LuaMetaTeX/LuaTeX, while for existing pdfTeX documents, keeping the font identical may be very important.
As noted at the start, there are some differences in philosophy between LaTeX and ConTeXt. For example, even if the 'LaTeX3' plans had been fully implemented, LaTeX would still pre-define design in classes or similar. ConTeXt does not do that, and that is a reasonable but contrasting position. As such, there are places that 'marrying the two' would be hard.
Best Answer
History
Knuth wrote TeX in the late 1970s because he wanted to typeset material as well as he could, given the limitations of his own knowledge and of the technology available at the time. It's generally agreed he did a pretty good job, but what he certainly was not trying to do was separate structure and style.
Lamport wrote LaTeX in the mid 1980s when he saw the need for a clearer separation of the two areas. LaTeX was revised in the early 1990s, and the current kernel dates from 1994 (with bug fixes, of course). This predates the HTML + CSS model by some time, and again technological limitations meant that further complication of LaTeX then would have been impossible. (In 1994, LaTeX was almost too large for many PCs, and the team worked very hard to squeeze it down.)
In the HTML world, new tags can be added and will be ignored by renderers which do not know them. That's not the case for TeX: unknown control sequences are errors. So we can't just add new concepts and expect existing documents to work: this is really important. So the decisions made in 1994 still have importance for LaTeX today.
ConTeXt is newer, and does separate out a lot more design than LaTeX 'out of the box'. ConTeXt also takes a different approach to stability than LaTeX, with a more active development outlook for the kernel. However, the ConTeXt approach is in some ways more like plain TeX than LaTeX, in the sense that ConTeXt keeps the design 'closer to the user' than LaTeX does.
Input and output
In the HTML world, a document is read entirely into memory to build the DOM for rendering. TeX does not work like that, at least unless we program it all ourselves. Instead, TeX reads a line and processes it before moving on to the next line. (LuaTeX can alter this, but I think even in ConTeXt it's still true that the TeX model is the main one.) As such, the approaches needed to alter appearance are very different.
A key thing to bear in mind when thinking about this area is what people want as output. In the TeX world, we are focused on high quality typesetting. As such, there will almost always be some manual adjustment of the design to reflect the realities of the content. That's not what happens in 'well written' HTML, and although it can be expressed in XML, it certainly breaks the strict separation. I and others would argue that this is no bad thing: you do need manual intervention to get the best results.
Tables
Tables are specifically mentioned in the question, and I think they deserve consideration on their own. In HTML, tables have been used for a variety of purposes. In TeX, there is a much more restricted approach to tables. Tables are famously complex beasts in the TeX world, and Knuth did point out that's it's amazing that they work at all! In most typeset documents, tables are used mainly for 'formal tables', and these have a pretty restricted range of 'good' appearances. As such, there is less need to provide the full range of CSS-like controls.
As canaaerus says in his answer, the TeX world is managed not by a committee but by no-one, and so what gets implemented depends on what individual users want. There are a range of table packages out there for LaTeX, plus the ConTeXt approach, and the raw
\halignin plain TeX. However, they are mainly trying to solve other problems, which tells you where the priority for users is.Looking ahead
As a member of the LaTeX3 Project, I know that we certainly are discussing better separation of content and design. One issue that is worth bearing in mind here is that the HTML + CSS model does not always translate well into what we want for typesetting. There are some significant differences between the two areas, and that means it's never going to be as simple.
Any better approach has to work with TeX, both in code terms and for interface. We have experimental code to deal with the relationship between objects ('l3ldb'), plus the idea of 'templates' for design, both of which are in this area.