You are absolutely right. A burndown chart tracks the completion of an expected amount of work in a set amount of time (hence why it is often used for sprints) and burnup charts are more open-ended, so are frequently used in releases and projects. There is nothing stopping a waterfall project from using one. However you will encounter two problems:
1) Waterfall projects claim not to be open-ended. I don't want to make over-generalizations, but many waterfall projects that I have been a part of claim that they know when work will be done through the project. The burnup chart is useless if you know that because it is an open-ended tool. Using a burnup chart would be admitting that your projections are guesses at best and while many project managers would agree that this is true off-the-record, putting it down on paper is harder.
2) You can't burn anything up (or down) on these charts until it is completely done. That means all development, testing, audit, release, all done. Many waterfall projects are designed to have everything come together at the end, so you'd never update your chart until the very end. If you are simply marking off tasks (coding a feature is complete, designing an architecture is complete) then you actually subvert the mechanics of the chart.