This is because WordPress considers the location stored in ABSPATH or a folder higher up to be version controlled:
if ( $updater->is_vcs_checkout( ABSPATH ) ) {
_e( 'This site appears to be under version control. Automatic updates are disabled.' );
And in the phpdco for is_vcs_checkout:
* Checks for version control checkouts.
*
* Checks for Subversion, Git, Mercurial, and Bazaar. It recursively looks up the
* filesystem to the top of the drive, erring on the side of detecting a VCS
* checkout somewhere.
*
* ABSPATH is always checked in addition to whatever `$context` is (which may be the
* wp-content directory, for example). The underlying assumption is that if you are
* using version control *anywhere*, then you should be making decisions for
* how things get updated.
So check the location stored in ABSPATH for one of these folders:
$vcs_dirs = array( '.svn', '.git', '.hg', '.bzr' );
If it does not contain one of those, go 1 folder up and check again. Note that these dot folders do not normally get displayed in folder listings unless you explicitly ask for them to be shown, nor will they be included in backup files.
If you still cannot find the VCS dot folder then you will need to ask your host. It’s possible that the filesystem you have access to is mapped on to the server using mounts so that only portions of it are in production, and the version controlled folder is elsewhere, but this is extremely unlikely to be the cause of your problem, and heavily implies a managed WordPress host. A very quick or even cursory glance at the hosts docs would reveal this, possibly even by reputation alone. E.g. WP Engine or WPVIP sites are always version controlled, and you have no control over updates from within the admin UI (and for very good reasons, the improved security of using version control being the biggest).