No - TableLayoutPanel is very powerful, but was designed to provide a very specific set of functionality. It is tempting to try to use it in all new Whidbey forms, but this generally leads to sadness and misery, specifically in the form of shoddy UI performance.

Here is a quick list of the sorts of UI that benefit most from the use of TLP:

• UI in which there are multiple parts of the Form that, when the Form is resized, you'd like to see grow portional to one another
• UI that will be modified or generated dynamically at runtime, such as data entry forms that have user-customizable fields added or substracted based on preferences.
• UI that should remain a fixed size overall (e.g. the dialog should stay under 800x600), but you need to support localized strings (see note above for an example of this usage)

Here's a list of types of UI that do not benefit greatly from the use of TLP:

• simple data entry forms with a single column of labels and a single column of text entry areas - you CAN use the TLP, but it doesn't buy you anything that v1/1.1 functionality would buy you (though see the localization FAQ below for more info on how AutoSize helps here)
• forms with the "one big thing" idiom - a form with a single large PropertyGrid, for instance - that should fill all the available space when a resize occurs - just use anchoring, since nothing else shoulw grow on form resize

Suggestions

• Avoid nesting TableLayoutPanels. The TLP is relatively performant, but it was designed with at most double-nesting in mind - beyond that, performance can suffer dramatically on resize.
• Avoid visual inheritance (putting a TLP in a base form and adding stuff in in the derived class). The code spit for this is not perfomant and usually this situation gets folks into trouble.