Je ne pense pas qu'il voulait autant dire «mauvaise conception» que «mauvaise pratique». D'une manière générale, une application Web doit être aussi apatride que possible. Même si, par exemple, vous pouvez avoir besoin de connaître les informations utilisateur afin d'autoriser l'affichage des pages, ces informations peuvent être enregistrées sur la machine client sous la forme d'un cookie et le serveur valide simplement les informations utilisateur à chaque fois.
Ce serait idéal, mais vous ne pouvez pas toujours compter sur le client pour pouvoir enregistrer les cookies. En outre, cela implique de valider l'utilisateur de manière sans état, ce qui implique potentiellement d'interroger des informations dans la base de données pour une simple demande de page. Souvent, il est simplement plus simple d'enregistrer ces informations dans la session.
Cependant, une fois que vous avez franchi le Rubicon, de nombreux programmeurs sont tentés de sauvegarder non seulement les informations d'authentification dans la session, mais aussi bien d'autres choses. Il s'agit d'un anti-modèle et tend à rendre votre application Web fortement dépendante de l'état, ce qui était précisément ce qui devait être évité en premier lieu.
Certains programmeurs s'appuieraient sur une technologie comme Spring (si vous utilisez Java) pour démêler ce qui serait autrement un gâchis de dépendances, mais je dirais que cela facilite la création de dépendances plutôt que leur élimination. De telles technologies devraient faciliter votre développement et non pas rendre votre anti-pattern moins problématique.
Par conséquent, une bonne règle de base est que si vous pouvez l'écrire sans état, c'est probablement une meilleure idée de le faire ou vous risquez de tomber dans ce piège. Évidemment, vous allez rencontrer des situations dans lesquelles cela est nécessaire, mais en règle générale, vous ne devez enregistrer que des informations qui seraient autrement difficiles à réacquérir.