Bon, ben comme je ne développe ni avec Delphi et encore moins sur W32 je suis prêt à mettre des limites à mon affirmation par manque de connaissances.
Mais comme le post initial parlait des Posix threads, je suppose qu'il ne s'agit pas de W32 (encore que je puisse me tromper sur ce point là également)

Ce disclaimer étant établi, voici mon point de vue résumé:

- les threads permettent de résoudre un problème de concurrence en n'y réfléchissant pas: on développe chaque thread comme s'il était tout seul et c'est bien parce que c'est facile;
- on se trouve très vite confronté au problème de l'accès partagé à des données (ou à toute autre chose partageable, comme du hardware pour ceux qui comme moi font de l'embarqué), et toutes les implémentations de threads apportent une solution, avec des mécanismes de synchronisation (mutex, sémaphores, variables de condition, ...) qui sont assez simples, en apparence en tout cas;
- on développe son système, on le teste au fur et à mesure de son développement, et tout va bien, jusqu'au jour où on le met en production, que la charge augmente, et que des bugs inconnus à ce jour apparaissent mystérieusement;
- on se rend compte que les mécanismes de synchronisation ne sont pas si simples, et surtout qu'ils ne peuvent pas être testés de façon exhaustive. Les conditions de course sont très rarement reproductibles de façon systématique;
- le comportement d'un système thread-based ne peut pas être facilement prédit par la lecture de son code (un comble !) car ce comportement se trouve plus dans les interactions entre composants que dans chaque composant individuel;
- ma conclusion troll: si j'ai un problème de concurrence et que j'utilise des threads pour le résoudre, je me retrouve avec deux problèmes au lieu d'un.

Les seuls problèmes qui peuvent être résolus simplement et élégamment par des threads, sont les problèmes où les threads n'interagissent pas (ex: un long calcul RSA dans son coin jusqu'à rendre la réponse, pendant ce temps le reste du programme continue à réagir à l'utilisateur)

Pour la plupart des autres cas, où ce que l'on veut est un programme qui réagit à beaucoup d'inputs possibles, mais qui autrement passe le plus clair de son temps à attendre ces inputs, le ractor pattern est bien plus approprié. Son utilisation se fait en général avec une librairie "callback-based", où les APIs ne sont jamais bloquants, mais auxquels on passe un pointeur de fonction à appeler quand le résultat est disponible. L'implémentation en Unix se fait en passant par le system call select() ou poll() qui permet d'attendre simultanément sur plusieurs file descriptors, et de traiter en série les événements au fur et à mesure de leur arrivée.
Si l'application n'est pas cpu-bound, la réactivité sera toujours meilleure avec ce genre d'architecture qu'avec un système threadé (le scheduling lui-même apporte un overhead pour le cpu). L'occupation de ressources (mémoire) est également bien plus faible en général.

La courbe d'apprentissage des threads est rapide, et c'est son danger parce qu'il faut beaucoup d'expérience pour développer correctement avec des threads, et encore plus pour débugger quand ça ne va pas, alors qu'un programmeur débutant a l'impression de suite de comprendre ce qu'il fait tant qu'il est dans son thread.
La courbe d'apprentissage d'une librairie event/callback-based est plus lente, juste parce que les langages ne sont pas conçus avec ce paradigme. Avec un langage OO de haut niveau (qui a dit python ?), en peut rendre la chose presque naturelle. En C (et j'ai développé un tel framework), un certain nombre de problèmes persistent, mais le développement est néanmoins incroyablement plus rapide et moins bug-prone (le management a d'ailleurs fini par me croire sur ces points). Les problèmes qui subsistent sont ceux inhérents au C (allocation de mémoire et pointeurs).

Voilà, j'arrête ici pour l'instant, parce qu'il y a sûrement d'autres réactions entre temps...