One argument which I am sympathetic to is that CMS’ are not interchangeable, nor interoperable, certainly not without rigging a larger workflow of middleman-solutions for API-communication. At that point you’ve basically built a CMS around the many CMS’.
Another is that all Static Site Generators (SSG), and I do mean all – I review and test a group of them yearly – of them are lacking in various ways. They either have some idiosyncratic, home-cooked way of doing things, do not follow standards, fail to separate concerns, or lock in content or design. Even the newcomers like 11ty, which seek to overcome this, end up doing very little that help the situation at all. The Jamstack-variants are the worst examples of lock-in and messing up concerns in years.
It is why I wrote the aforementioned plugin; Grav is in no way optimized for generating static content, and thus it is not an ideal or fast solution that works out-of-the-box. The case remains for agnosticism about the CMS, and still wanting a solution for serving static content with PHP as the system and Twig as the rendering-engine.
Sadly other PHP solutions for SSG’s are below par, which is why CMS’ have specific ones like the plugin or any of the static-generation plugins for WP. For documentation-purposes I have used the Scholar theme with the Static Generator plugin, but it is more technically involved.
In which regards the previous posters, pamtbaau and hughbris, are correct. If you are looking to host documentation – with features that typically go along with that – you’ll get it set up much faster and can focus more on content when hosting with a Git-service and building with Hugo, Jekyll, or any Jamstack-solution such as Hexo. You don’t need and don’t want to use a whole server running off of Debian for that.