Technically speaking everything that is being done, has already been done or has to be done on a project must go to WBS. In other words anything that is not on WBS must either not be done or added to WBS.
Please excuse me if it does not sound very polite but there is no scope for what you think and what I think here. What is right is right. WBS must contain no less than 100% and no more than 100% work on the project. It is a living document and is updated very frequently until the closing stage.
It might not always be possible to have a perfect and complete WBS in the beginning. Very often, and particularly in the crisis situation, we might need to call emergency meetings or work on work around plans that were not there in the WBS. In such a situation, the new tasks are added to WBS and the task of adding the tasks on WBS, which is itself a task is also added to WBS.
I am not adverse to the idea of avoiding putting very minor tasks to save time and effort. However, we must acknowledge that that would be a compromise and not the correct way. That might also be the best way in certain situations, but again that will not be the correct way. After all sometimes the correct way is not the best way.
Some of the project tasks that are apparently small in nature can be grouped together into a task of visible magnitude. For instance the "secretary's time to send your package to a vendor" might be grouped with an adjacent task or a few. If it is not, then where else do you show it in the plan? We cannot put it in the schedule if it is not in WBS.
On the other hand meetings are not considered small tasks and must go to WBS without fail.
Coming back to WBS, what is WBS after all? Is it just a planning tool? The fact is that it is more a communication tool. It is used to communicate scope of the project or all the tasks that would need to be done to realize the scope of the products (derivable) of the project, to the stakeholders. After the WBS, supported by the WBS dictionary, is approved by the stake holders, particularly by the customer, the sponsor and the project team, the same document is processed and elaborated to make more than half of the project documents. The cost estimates, budget, final costing and invoices, etc everything is based on WBS.
However, there is a catch. Customer will never be happy to see "secretary's time to send your package to a vendor" on his cost breakdown statement. Customer is interested in how much it totally costs him to send the package. Customer wants to drill down, but does not want to go beyond a certain level of granularity. Therefore, the WBS presented to customer along with the cost estimates or cost break down statement looks a bit different. We do not have to prepare two WBS, but just roll up the activities to the control point level.
Another thing to consider is the two groups of tasks namely value adding tasks and non value adding tasks. What if the customer says, "I will not pay for the secretary's time, why can't the manager spare two minutes to send the package?" What if the customer says, "I won't pay for the project manager, let the programmers manage the project themselves." How do we handle such a situation? The solution is simple; we do not show any task on the cost plan that can be attributed to a single person. We instead show groups of tasks which together are value adding, a derivable or a tangible part of the derivative. Now the question is, is schedule a derivable? Of course it is. Then who says the tasks involved to create a schedule, pure project management tasks, are not shown on the WBS? Is CPI within some range and SPI within some range not a requirement? Then who says the tasks required to be done to achieve that are not shown on WBS?
To conclude, the 100% rule which states that WBS includes 100% of the work defined by the project scope and captures all deliverables - internal, external, interim - in terms of the work to be completed, including project management is no non-sense. It is simple and accurate.