There are a couple of examples I can think of, without going into detail.
Consider a (not too distant future) dotProject package, where an admin has control over 30 or so subsites, each focused on a manufacturing or construction project. Each subsite uses a series of cron reports to track project progress. Some might create indexed ratios from data for financial officers, other indexes might be for project managers, functional management (operations), and stakeholders. Other reports might notify resource controls (inventory, HR etc.).
The point is that most of the reports would be identical across all the subsites, only changing by project name/id (relevant dbs [if named differently] and perhaps report cycles. If a query was considered new every time a project started to use the report for the first time, the load would become very tedious. The load from mistakes in editing and delayed report generation (as each query is painstakenly put in a que for authorization) could be higher than the security risk involved in adding an optional parameter feature.
Based on your most recent comments of this being a UI issue, are you stating that queries already have this level of flexibility --without editing?
