I would not suggest using disabled tasks to store comments. You can use multiple annotations in the control flow and data flow. You can put one next to each task if you want.
I would suggest:
A header annotation that gives a brief (few sentence) description of what the package does.
Make sure each task has a meaningful name that briefly describes what it does. An Execute SQL task with a name like “Truncate Staging Tables” probably doesn’t need too much more documentation.
If the tasks lend themselves to being placed in groups use sequence containers and give the containers descriptive names. This helps to give a high level overview of what the package is doing.
If your packages have Execute SQL tasks I would put the SQL in stored procedures if at all possible. Stored procs are usually more conductive to adding inline comments and can give some separation between the package and the database.
If you are creating the SQL dynamically and then executing the string have an annotation next to the Execute SQL task that has an example of what the final SQL statement should look like. This way you don’t have to pick through the package and try and build the statement yourself. The annotation might also contain comments as to what variables, expressions, script tasks etc contribute to the SQL statement.