Whether or not you need to decompose the task into so many levels depends on the task complexity or amount of content. There's also the classic depth-breadth tradeoff. In general with web apps, where you have large windows and slow page loads, you're better off with a few complex pages in a simple hierarchy than a lot of simple pages in a complex hierarchy. However, it's possible you have a very complex task that requires with lots of complex pages, so maybe you must have many levels.
But that is not especially related to the type of control used to access those levels (e.g., tabs). I'll assume you've optimized the AI hierarchy, so it's a question of whether you want to use tabs to access it or not.
Guidelines Say One Level
Just to be clear, by “number of tabs,” you mean number of levels of nested tab controls, not number of tab panels per level. The Windows 7 UX Guidelines give a specific and unambiguous answer: 1.
Don’t nest tabs or combine horizontal tabs with vertical tabs. Instead, reduce the number of tabs,
use only vertical tabs, or use another control such as a drop-down list (p182).
I believe the main concern is the users can get lost in the hierarchy with nested tabs. All tabs look alike so it’s easy for users to confused the level they’re on and the level of the tab they're clicking. Plus a tab within a tab is a weird metaphor.
Not So Sure it Applies to Web Apps
As a general rule, what applies to desktop apps applies to web apps. Desktop apps have been around longer so they have had more time to figure what works, presumably through their own usability testing, although I'm not aware of anything published on this particular issue.
In this case, I’m not so sure this no-nesting guideline applies. With a web app, you have greater latitude in the visual design, so it seems it would be possible to clearly divide and distinguish the tab sets from each other and make it visually clear what tab set is within what tab set. Kingsburg (2004) shows how you should combine sidebar and top menus, for example. Tabs are just menus with a metaphorical kicker, so the results should be applicable to tabs too.
Do you buy that? I’m not sure I do. When you have reason to believe an established guideline doesn’t apply, don’t just disregard the guideline. Test your alternative it in a usability test and see if it creates the problems the guideline was trying to avoid.
Alternatives to Tabs
As I said, tabs are a type of menu, so the alternatives are other kinds of menus. Which is best is a matter of trading off clutter per page with mechanical access (number clicks and scrolls) to the pages, which in turn depends on which pages users tend to access in what sequence and how often.
You can have a static hierarchical sidebar menu, showing options indented within options, explicitly showing the AI hierarchy. This can provide one-click access from any page to any page, but can mean scrolling if the menu is tall, and can take a lot of space that otherwise would be for the actual content.
You can use a tree control for the menu, basically a hierarchical sidebar menu where the users can open and close various levels to show the options they are using. Now the menu takes less space and less scrolling, but more clicking. It’s good if users get to given level then move among the options at that level. This has about the same clutter-mechanics tradeoff as nested tabs, so it may be your primary alternative.
You can have pulldown/dropdown and cascade menus, basically a tree that “closes up” automatically. Now you’ve minimized space used by the menu, but to go to another page, the user has to start over from the top –lots of clicking. It’s best when the users tend to go down to one page and stay there for the rest of the session.
You can have home page that’s nothing but a static hierarchical menu (if it won’t reasonably fit in a sidebar). Each page of content has only a home link. Advantage: no menu taking up content space, and only two clicks to any page. Disadvantage: two clicks to every page.
And, of course you can have combinations of the above. For example a, you can have a two-level pulldown that can bring the user to a page with a multi-level tree to access a page which has a single-level tab on it. While you're at it, throw in a bank of expanders. Or, if you find yourself doing that, maybe you need to reconsider the complexity of your app.