I don't think he meant "Bad design" so much as "Bad practice." Generally speaking, a web application should be as stateless as conceivably possible. Even though, for example, you may need to know user information in order to authorize page viewing, that information could be saved on the client machine in the form of a cookie and the server simply validates the user information each and every time.
That would be ideal, but you can't always count on the client being able to save cookies. Furthermore, it involves validating the user in a stateless fashion, which potentially involves querying information from the database for a simple page request. Often times it's just simpler to save such information in the session.
However, once you've crossed the Rubicon, a lot of programmers are tempted to save not only authentication info in the session but many other things as well. This is an anti-pattern and tends to make your web application heavily dependent upon state, which is precisely what was supposed to be avoided in the first place.
Some programmers would hinge on technology like Spring (if you're using Java) to untangle what would otherwise be a mess of dependencies, but I would argue that that only makes it easier to create dependencies rather than eliminate them. Such technologies should aid your development, not make your anti-pattern less of a problem.
Therefore, a good rule of thumb is that if you can write it stateless, it is probably a better idea to do so or you risk to fall into this trap. Obviously you're going to run into situations in which this is required, but generally speaking, you should only save information that would otherwise be difficult to reacquire.
