I have designed similar functionality for my ETL jobs - sending out row counts, sums and last-date information by e-mail at job completion.
I’ve opted for your option 3. At the end of the job, I added a Workflow to email a job report summary in which I placed a Script task that called a number of custom functions to gather the data required and compile the e-mail.
(The custom functions in turn would query specific ETL job log tables in the DWH and run counts and sums over key fact tables and certain key dimensions).
Some additonal but not required information. Feel free to skip 
All my Workflows used a Try/Catch approach and when an error was encountered, it would call a custom error handling function. This function would do a number of things including populating some global variables to indicate that an error had happened and in which workflow and also write this information into an error log table in the datawarehouse.
Based on certain flags, certain downstream workflows would or would not be executed based on the workflows affected by the error. The reasoning for this was that while certain areas would be negatively impacted - other non-related areas of the datawarehouse would still need to be populated. This all depended on business requirements.
(Example: in our case, it was a business requirement to load all P&L impacting transactional data even if the dimensions themselves were not completely loaded e.g. loan arrears data, mortgage account balances, bond trading transactions vs customer, loan or asset dimension data. The incorrect dimension data would be corrected during the weekend or at another point in time).
Based on the global variables indicating the occurrence of an error, the ETL process summary workflow would use the “succesful load”, “load with low priority errors” or “critical error during load” e-mail templates. If an error had been detected, the workflow would also call custom functions to query the error log tables to retrieve a list of all affected workflows.
Originally we were using the standard email functionality to send parts of the log file but we just found that we wanted more control over the layout and content of these emails. Also the emails themselves were designed to give the ETL administrators a warning that an error had happened - who would then log into the Management Console to investigate the problem.
Sending chunks of the log file was just not going to be very helpful, especially when you try reading those e-mails on a Blackberry screen.
ErikR
(BOB member since 2007-01-10)