Yes that's right the config export will recreate them for its config sync handling. The /module/config/install and exactly that just for install time. The config syncing would become a big mess of overlaps if every module could define different elements to handle syncing themselves. Is that such a problem that config sync has them? As that can be your master of that the view should contain. So think of it as: The module sets up the default upon install and Drupal's config sync will make a copy so that's now the master and won't get removed unless you remove it through the UI and then do a config export.

If people are paying attension it should hopefully be unlikely someone would delete a view from the UI, do a config export and do an import on live without realising they've messed up. But just in case have you thought about adding your config sync directory into GIT? So that if someone does say delete a view through the UI and do an export you'd be able to revert

Yes that's right the config export will recreate them for its config sync handling. The /module/config/install is exactly that, just for install time. The config syncing would become a big mess of overlaps if every module could define different elements to handle syncing themselves. Is it such a problem that config sync has them? As that can be your master of that the view should contain. So think of it as: The module sets up the default upon install and Drupal's config sync will make a copy so that's now the master and won't get removed unless you remove it through the UI and then do a config export.

If people are paying attention it should hopefully be unlikely someone would delete a view from the UI, do a config export and do an import on live without realising they've messed up. But just in case have you thought about adding your config sync directory into GIT? So that if someone does say delete a view through the UI and do an export you'd be able to revert