100.0 % of the requests to the ELB are erroring with HTTP 4xx when autoscaling capacity is 0

The issue you're experiencing is related to how Elastic Beanstalk evaluates environment health when your auto-scaling group scales down to zero instances.

When you schedule your environment to shut down by setting the desired, min, and max capacity to 0, the load balancer has no healthy instances to route traffic to. This causes the load balancer to return HTTP 4xx errors for any incoming requests. Elastic Beanstalk's enhanced health monitoring system detects these errors and reports them, causing your environment health to fluctuate between "Unknown" and "No Data" states.

This behavior is expected when there are no instances available to handle requests. The "No Data" state occurs because there are no instances to collect health data from, while the "Unknown" state occurs when Elastic Beanstalk detects that 100% of requests to the load balancer are resulting in 4xx errors.

To address this issue, you can customize the enhanced health rules for your Elastic Beanstalk environment to disregard HTTP 4xx errors originating from the load balancer. As of April 2020, Elastic Beanstalk supports customization of load balancer enhanced health rules, allowing you to ignore these 4xx errors during periods when your environment is intentionally scaled down to zero.

Another approach is to adjust the health check grace period for your Auto Scaling group. This gives instances more time to start up and become healthy before they're subject to health checks, which can help during the morning startup process.

These fluctuating health states don't necessarily indicate a problem with your setup if they only occur during the scheduled downtime when no instances are running. It's the expected behavior when the load balancer has no healthy targets to route traffic to.
Sources
Elastic Beanstalk: ELB Health Check Fails During Auto-Scaling Down | AWS re:Post
Troubleshoot a Classic Load Balancer: Health checks - Elastic Load Balancing
Release: Elastic Beanstalk support for load balancer enhanced health rule customization on April 20, 2020 - AWS Elastic Beanstalk

It is possible that you have multiple rules and a different rule is being picked that it sending traffic to the ASG.

In this example, I only have a single rule that sends traffic to fixed response and it works just fine. So, maybe check all your rules. For example, you might have rules for both port 80 and 443 and only one of those is being updated to provide fixed response.