A mon sens mélanger FW et RP sur une même machine physique est non seulement un risque de sécurité mais surtout une erreur d'architecture (au sens urbanisation) et d'exploitabilité. J'ai vu de nombreux FW commerciaux (au hasard checkpoint et son module web filtering) utilisant ses fonctions en prod devenir rapidement de véritables usines à gaz inexploitables avec le temps et la multiplication des fonctions. Ceci est même risqué, car très souvent dans ce type d'appliance commercial, il n'y a pas d'HTTP en asic et c'est le CPU qui traite les règles applicatives en soft. Conséquence, les perfs s'écroulent avec la multiplication de règles applicatives.

De tels équipements, ainsi utilisés, finissent par être des spof qui se trouvent sur beaucoup de chemins critiques et deviennent avec le temps un gouffre financier. Segmenter son architecture par protocole et niveau en gardant une architecture simple et homogène me semble dans beaucoup de cas comme étant une bonne pratique pour construire des architectures durables, évolutives, maîtrisées et sécurisées.

Un FW est un équipement majoritairement réseau (1-4). Un LB qui supporte du SSL, que je considère comme un RP car il implémente nécessairement des fonctions applicatives (persistance de session, cookie, ...) est un équipement de niveau applicatif et réseau (3-7). FW et RP sur le même serveur risque de faire double emploi sur la partie réseau, ce qui peut être le cas lors d'un incident, d'un bug ou dans l'urgence. Surtout au vu de la complexité des applications et des SI et de la difficulté du debug des applications distribuées.

Cela ne veut pas dire que c'est à proscrire car encore une fois ça dépend des cas. On peut par exemple se demander si votre serveur n'est pas sur-dimensionné ou s'il n'est pas plus intéressant de le virtualiser au vu des ressources restantes et de l'overhead que cela implique.