Ce n'est pas parce que ce n'est pas le chemin qu'il faudrait suivre que ça veut dire que personne ne peut le faire.

Ce que je veux dire, c'est qu'un excellent développeur peut faire un chef de projet minable (et vice-versa) car ce ne sont pas les même compétences.

Pour avoir été dans ce rôle, je sais que je ne suis pas bon en contact client, et c'est assez handicapant pour être CP.
Il faut que les développeurs comprennent qu'il existe pleins de manière d'évoluer dans leur métier sans nécessairement devenir chef de projet, et que les managers comprennent qu'ils peuvent doublement risquer une équipe en passant leur meilleur développeur chef de projet : perdre leur meilleur élément et placer un mauvais manager à la tête de l'équipe.
Dans ma conception, un chef de projet n'est pas un développeur, mais un consultant, et il doit savoir s'appuyer sur les compétences de son équipe pour faire ses prévisions, mais il ne doit pas être un sur-développeur, car il est sûr de se perdre.

Maintenant, le monde étant fait de tout sauf de noir et de blanc, mais de toutes les nuances, il existe des tas de cas où cette évolution a été un succès

C'est précisément là qu'est visible l'ampleur du problème : désigner de nouveaux chefs de projets.

Je recommande vivement la lecture d'un ouvrage qui synthétise fort bien tout ça : « Le principe de Peter » (qu'on peut trouver à la FNAC) VU le prix, ça ne mérite même pas une hésitation quant à la décision d'agrémenter sa bibliothèque

Parce qu'en fin de compte, on aboutit sur « la promotion » qui est ou non une bonne idée selon le promu considéré

Je connaissais plutôt le principe de Dilbert, et un autre dont je ne me rappelle pas le nom, qui dit que quand un manager doit choisir un manager, il ne prend pas le meilleur, car il va diminuer la puissance de son équipe

Je ne connaissais pas le principe de Dilbert, mais la description faite dans le lien que tu indiques est en fin de compte une élaboration d'une des réponses du livre Le principe de Peter qu'il nomme « l'arabesque latérale » qui consiste à promouvoir un employé ayant atteint son niveau d'incompétence à un poste où il sera le moins à même de pouvoir nuire à l'ensemble, avec un titre ronflant pour ne pas le vexer, une augmentation symbolique si tant est qu'il soit assorti une augmentation à ses nouvelle qualifications mais surtout le moins possible de subordonnés, en résumé, on le met sur une tablette pour l'oublier là le plus longtemps possible.

Le Principe de Peter analyse le problème de la promotion dans tous ses aspects en évoquant tous les cas et en s'attardant en particulier sur ceux qui sont hors-norme. Dans pas mal de cas, les gens promus restent compétents dans leurs nouvelles responsabilités. Reste le problème de savoir qui promouvoir. Il y a des catégories de gens qui ne seront jamais promues : les super-incompétents et les super-compétents. Les premiers pour des raison plus qu'évidentes, les seconds parce que ceux qui seraient en mesure de les promouvoir ont peur pour leur propre place.

Il reste qu'en fin de compte, on peut dire que devenir chef de projet, ce n'est pas uniquement une question de diplôme ni une question d'expérience : c'est un problème de personne qui a les capacités professionnelles ou au moins les capacités d'apprentissage nécessaires pour acquérir les compétences requises pour accéder à des responsabilités plus importantes.

Je m’immisce dans le débat. Tout dépend de la taille de l'entreprise, du découpage des métiers et des responsabilités réelles du chef de projet. Etre CP fonctionnel ou technique sont 2 métiers différents dans certaines boites mais un seul et même boulot dans les autres (généralement dans les PME). Ce que je veux dire c'est qu'il est plutôt logique de passer de développeur vers un poste de CP technique (ou référent technique ou analyste technique, selon les nomenclatures) ; alors que c'est moins évident de passer de développeur à CP fonctionnel.

Disons que selon moi, le fonctionnel est différencié du technique tout en étant intimement lié (surtout dans les métiers du Web pour lesquels la technique peut avoir un impact structurant sur les fonctionnalités). Cette différenciation permet de séparer les responsabilités :
- responsabilité vis à vis du besoin client, des fonctionnalités et du client pour le CP fonctionnel
- responsabilité vis à vis de la qualité, des performances et de l'architecture pour le CP technique

Les 2 travaillent donc de concert pour produire l'application correspondant au besoin. C'est une vision personnelle, chacun a son parcours et son expérience.

Oui expérience ne signifie pas études, et vice versa. L'un ne remplaçant pas l'autre. Si l'un vaut mieux que l'autre, tout dépend des spécificités sur poste, des employeurs, ...
L'expérience tu peux en acquérir tout le temps, les études c'est plus dur forcement.
Pour ce qui est d'être chef de projet directement, je pense que l'expérience va primer.
Pour ce qui est du salaire, les paramètres sont tellement divers et variés qu'il est bien dur de répondre à ta question.