The “autoupdate” value you see there is just a string in the “response” field from the version check API call. It doesn’t determine whether or not your site actually performs an autoupdate. You’ll see that field in every response returned from core version checks. Basically, it’s just saying that a potential autoupdate is available for download.
The WordPress updater actually has a function called should_update_to_version() which determines whether or not WordPress performs the update. Because ultimately, the API server isn’t doing the update for you, your own install of WordPress is doing that. The should_update_to_version() function uses a combination of various defines, filters, and defaults to determine whether or not it should do an update in a wide variety of circumstances.
For example, minor updates (4.0 -> 4.0.1) are enabled by default. Major updates (4.0 -> 4.1) are disabled by default. But there are more variations on that theme. Beta versions, such as 4.1RC1 will update to to their release versions by default. If you use pre-release versions for testing, like the upcoming 4.2-alpha or whatever it will be called, then you may want auto-updates to the latest nightly releases. Things like that. So the function is a bit more complex than it first appears.
If you have not changed the defines, and you don’t have any plugins or themes that are using the various filters to change the way the updater works, then WordPress will not update itself from 4.0.1 to 4.1 automatically. Check to see if you have any plugins or other code that modifies the core update mechanisms.
Additionally, some hosts may be doing the updates for you. Ask your host if they have any such systems.