A lot of software is capable of adjusting its config file, but by far most users just use the default. Snaps are designed to be isolated from each other, and to various extents depending on interface connections, the host filesystem. Access to a dot file in home is typically not a justification for classic confinement.
In the specific case of ~/.dunner.yaml, it still isn’t clear to me why this is required. HOME is set to ~/snap/dunner/<revision> such that the you can write to anywhere in $HOME (eg, $HOME/.dunner.yaml (which is ~/snap/dunner//.dunner.yaml), $HOME/.some-other-dunner.yaml (which is ~/snap/dunner//.some-other-dunner.yaml), etc).
For cases when HOME is not sufficient, there is the personal-files interface. The interface is intended to be read-only for importing an existing configuration from a non-snap install, but also supports write. Please note that there is a review process for use of the personal-files interface (specifying ‘read’ is typically fine so long as it is clear that the application is the owner of the file (which for Dunner, ~/.dunner.yaml is clear) but use of write typically requires justification in terms of compatibility and robustness of the snap to not break non-snap install and vice versa.
All that said, the initial request only discussed ~/.dunner.yaml, where, as stated above, there are various means to address this with a strict mode snap. However, you later said that your requirements are similar to goreleaser which has many other reasons to be classic. Assuming that your snap could be adjusted to handle ~/.dunner.yaml in strict mode, are you saying there are other reasons why this must be classic? If so, please describe typical use cases.