Technically, it is entirely possible for a web server to return different content depending on whether you accessed it via HTTP or HTTPS. In fact, nearly all servers supporting HTTPS do this; if you access /foo/bar via HTTP, you get a redirect to HTTPS, and if you access it via HTTPS, you get page content (or at least a 404). It's rare (though not unheard-of) for this redirect to itself have a vulnerability, so it's worth testing. Additionally, it's a good idea to know what content your web server makes available over plain HTTP - sometimes sensitive data is exposed! - and also some web apps will send a user from HTTPS to HTTP for some links/requests and that gives a network attacker a good opportunity to steal cookies, data, or begin an SSL-stripping attack; you definitely want to find such things.
Pretty much the only time that you can completely ignore plain-text HTTP is if you use HTTP Strict Transport Security (HSTS). A user visiting the site for the first time will presumably neither be sending nor receiving sensitive data in their first request/response, and will be immediately redirected the HTTPS and then the browser will not allow any further HTTP requests to that domain once it sees the Strict-Transport-Security header. Some very old browsers don't support HSTS, but... well, anybody using a browser that old is metaphorically wandering around picking up random guns, aiming them at their foot, and pulling the trigger; it's not your job to try to stay ahead of them and unload every gun they might find first.
Scanners generate so many requests already, and HTTP->HTTPS redirects are so light on server resources, that I don't expect you have any need to worry about extra scan time or server load. Scanners are generally "smart" enough to not bother with HTTP requests when every time they try one they just get a redirect in response, when they see HSTS headers, and/or when all cookies are set with the Secure flag so somebody using HTTP instead could only make unauthenticated requests.
