Assigning a qualitative label like "better" is almost impossible to do. Each procedure has a purpose and a particular way of doing things. For example, PROC TABULATE is a very powerful procedure which can be used for summarizing data and producing summary reports with many crossings of variables in the table dimensions -- page, row, column.
PROC REPORT is also a summary procedure -- with the added advantage of also being able to create detail reports. So, for example, if you wanted to show the number of visits per patient and doctor (a summary report) you could use either PROC REPORT or PROC TABULATE. But, if you wanted to show a detailed list of each vist for each patient showing date, doctor and length of visit, with a summary line that showed the total number of visits after the detail lines for each patient -- then you can only create that report with PROC REPORT (or PROC PRINT or a DATA step program).
Neither procedure is "better" -- each procedure is "better suited" to different tasks. You just can't ask TABULATE to do a detail report -- so PROC REPORT is better suited to producing a detail report. You can't ask TABULATE to calculate a report column that doesn't exist in the data. PROC REPORT has the ability to use DATA step logic in a COMPUTE block to calculate report columns. On the other hand, while you CAN ask PROC REPORT to produce a cross-tab report with nestings in both the rows and the columns, PROC TABULATE (in my opinion) is easier to use to construct tables with many nestings or crossings. The Universal class variable ALL, used with PROC TABULATE makes it easier to get totals/subtotals in any dimension. Plus, PROC TABULATE has a PAGE dimension, as well as Row and Column dimensions to its tables; while PROC REPORT only has Rows and Columns in its tables. PROC REPORT gives you greater control over customizing breaks or inserting LINES in the report at a break point. . . . the list goes on.
Experience with both procedures is the best way to determine which one is better suited for a particular report.
The Summary Tables task generates PROC TABULATE code. Currently, there is no EG method for generating PROC REPORT code....although there may be an EG interface to PROC REPORT in the future.
When you use ANY task with SAS to perform analysis, you generally can find a "Preview Code" button in the lower left-hand corner of the task pane. Then once the code window opens, there is usually an "Insert Code" button that allows you to modify the code generated by the task. Of course, knowing the syntax of the procedure is very useful when you start modifying code. In addition, you can see the last generated/submitted code for a task (such as the Summary Tables task) and you could save that code to a separate file and use it as a starting point for making modifications.
When I had time to write code away from hunting Brontosaurus for dinner , I loved to play with the Tabulate procedure guided by the book written on the subject by Lauren Haworth. I still find some low level details such as cell percentage by grouped row take a little more time to get right than I'd prefer, but the power of the procedure for laying out data has always meant it is a favourite.
The table designer gives a great start for structuring your code, and you can then play with nested variables, statistics, labelling and summarising. Lauren's book was always one of the first four I recommend to new users and clients, although now I suggest users start with the Little Enterprise Guide book by Loren Delwiche and Susan Slaughter, and follow on with the Haworth book.
Enterprise Guide is a favourite product because it makes the introduction of the very powerful reporting and graphics tasks in SAS easier for the newcomer. The online SAS help is excellent for exploring syntax of procedures, although if you don't have Foundation SAS on your desktop, then you'll need to access the full syntax through the Support website. The documentation link will get you to "http://support.sas.com/documentation/onlinedoc/index.html" where you can select and explore any procedure.
I also believe in not reinventing the wheel, so often search support.sas.com for conference papers where specialised use of SAS procedures is discussed and available as a template.