Die splitsing tussen voorgrond taken en achtergrondtaken gebeurt al heel lang hoor. De GUI van een applicatie loopt altijd in een andere thread(meestal met hogere prioriteit) dan de eigenlijke logica. Indien dit niet zo zou zijn dan hangt je keihard vast iedere keer je op een knop klikt tot de actie geassocieerd met die knop helemaal uitgevoerd is.
Je zult nog verbaast staan bij de hoeveelheid single-threading applicaties die je gebruikt. Dat je dit niet merkt, dat komt omdat de uitgevoerde taken vaak erg klein zijn.
Zolang je nog maar zorgt dat de taak die je uitvoer minder dan 250msec duurt (oid, soms kun je 'm zelfs wel 1 seconde of meer laten duren), zal de gebruiker er niets van merken.
Iets als een spellingscontrole gebeurt, vermoed ik, al helemaal op de achtergrond in een ander thread. Het zou zelfs moeilijker programmeren zijn om dat niet in een aparte thread te doen.
Ik denk dat je je niet beseft hoe lastig het is om een multithreaded applicatie te programmeren. Het lijkt misschien erg gemakkelijk, maar ik kan je zeggen dat het lastiger is dan je op het eerste gezicht zou zeggen.
Ook browsers kunnen zonder problemen meerdere threads gebruiken om meerdere pagina's tegelijk te renderen. Maar heel veel voordeel merk je daar niet van.
De bottleneck is veel vaker iets anders, het netwerk bijvoorbeeld bij een browser.
En iets hierarchisch als een html-pagina in meerdere threads renderen is niet echt triviaal en de winst die je haalt echt minimaal (i.e. 50ms naar 30ms brengen levert je niet veel op naar gebruikerservaring)
De browser wordt meer en meer als applicatieplatform gebruikt met client-side JavaScript, het opdelen van de taken die de browser uitvoert is dus wel degelijk lonend. Als zou je de applicatie al zodanig opdelen dat iedere tab/venster een eigen thread krijgt, voor zover ik weet is dat nu namelijk nog niet zo.
Je hebt overigens wel gelijk dat het parsen van HTML niet iets is dat je over meerdere threads moet gaan verdelen, maar dat heb ik ook helemaal niet voorgesteld

Ik denk dat je je niet beseft hoe lastig het is om een multithreaded applicatie te programmeren. Het lijkt misschien erg gemakkelijk, maar ik kan je zeggen dat het lastiger is dan je op het eerste gezicht zou zeggen.
Aan de andere kant valt het ook wel weer mee. Zodra je een beetje gevoel begint te krijgen voor alle moderne threading primitieven die een moderne concurrency library je biedt EN je niet al te gekken dingen doet dan valt het echt best mee.
Je moet niet enkel met een Process of Thread werken en lukraak al je data sharen en dat op een lukrake en chaotische manier. Maak je echter slim gebruik van dingen als barriers, blocking queue's, (timed) reentrant locks EN laat je je threads eenvoudige goed gedefinieerde taken uitvoeren met het liefst een sporadische communicatie dan is het echt niet zo moeilijk.
De grap is dat veel van de principes die je gebruikt om parallel te programmeren dezelfde zijn die je ook al zou moeten toe passen bij sequentieel programmeren. De OO principes low coupling, high cohesion zijn hier uit stekend van toepassing.
Volgens mij gebruikt IE7 iets wat wel redelijk op 1-thread-per-tab lijkt, alleen je merkt gelijk dat IE7 sloom is met het openen van een tab. Firefox en Opera gebruiken voor zover ik weet verschillende threads per onderdeel (ie: thread userinterface, thread netwerk, thread javascript etc). Overigens zijn de threads van IE7 waarschijnlijk vooral informatiecontainers als het ware, waarbij vervolgens het renderen etc weer word doorgegeven aan een centrale renderthread. Hierdoor zou IE7 minder crashgevoelig moeten zijn (als 1 tab crashed zou de rest moeten blijven bestaan), maar ik merk persoonlijk nogal duidelijk dat het extra tijd kost om een tab te openen.