In general, I don't like shared hosting. Somewhere between big pretty interfaces and having to fax in my drivers license for basic shell access, there exists an aversion to someone else looking over my shoulder while I play with the limited configuration options they allow me.
Shared hosting is like the McDonalds of the web, it's great for most people, but good chefs wouldn't consider it real food. It's not that it's necessarily bad, it's just that the flavors have been finely tuned to fit every pallet. Shared hosting is the same way, it's tuned to support everything well, but nothing in particular. But the danger in having your meals prepared in much the same way is that you never really learn how to cook.
Most web developers have little to no idea what goes on behind the scenes for an application. When something unexplained goes on, they open a ticket and wait for it to be magically fixed. Knowing an application stack doesn't mean knowing the transaction down to the protocol level (tho it can't hurt), but having enough knowledge to gain an instinct about what might be broken when things start breaking is important.
Reading articles and books in regards to the application stack of choice is one thing, but the only real way to learn something is to do it. In the doing, you'll find where things can go wrong. When things do, the most valuable lesson isn't how to fix the issue, but developing the skill set to learn how to fix problems is the key. When you know where to start a problem, no issue will appear too complex. Many problems with technology share the same roots, and exhibit the same symptoms, and as such, have similar solutions. Identifying those common roots gives you the background to know where to start working on a presented problem and eventually come up with a solution. That solution may not be the ideal, that comes with experience, but when the server is down at 4:30 on a Friday while the sys admin is on vacation, any jury rig that gets things up and running again is better than just giving up.