One VPC per customer is not going to scale for long if you're successful. This is a soft limit (i.e. it can be raised) of 5 VPCs per region per account, I don't know how high AWS will raise it.
There's a soft limit of 5 elastic IPs per account. I assume AWS would be willing to raise this, but IPv4 is a scare resource so I doubt they would give you a huge number of them. Of course each instance gets a public IP address, but it changes if you stop / start the instance.
NAT is for egress, not ingress. I don't think it's going to help you. If you can use a single IP with each customer on a specified port, proxied through a central account, that would be efficient and would scale. You may have problems with firewalls though, and it means you may pay for traffic twice - once into the proxy, then once out to the VPC / account that services it.
Transit gateway provides connectivity to virtually any number of AWS VPCs, in one or many accounts. It's easier than VPC peering as it's a hub and spoke architecture rather than point to point.
If you don't want your accounts taking to each other, just to a central account, you can put firewalls in place for account isolation. I use NACLs for that, reserving security groups for tiering (web, application, db, etc). I've largely automated NACL creation using CloudFormation for my current project - we deploy virtually everything as code.
Transit Gateway charges per VPC attachment. From memory it's a bit more expensive than VPC peering, but VPC peering might charge for data both being sent and received which would make it similar. I haven't looked into this in detail because enterprises don't really care about the cost of bandwidth, within reason.
Your requirement to use one Elastic IP to be delivered to multiple VPCs cannot be done by Transit Gateway. That would probably have to be done by something like Nginx running in an instance, though maybe you can look at ALB / NLB for this. I don't have time to fully consider your requirements and create a solution at the moment.
IPv6 has a very large number of addresses. If your clients can support IPv6 that's a solution that will scale. You don't need elastic IPs for IPv6, you allocate an IPv6 range to your VPC and its yours with no NAT.
You're still going to run into the VPCs per account limit with this option.
A multi-account architecture with one account per customer would be easier to scale and would avoid the limits. Use AWS Control Tower to manage the accounts. Transit Gateway can do inter-account networking for you, but beware of costs.
Multi-account is not particularly difficult to manage. You set up an AWS organisation and your billing information goes in there - credit card or you can arrange monthly invoices with AWS. You can create new accounts either with AWS Organisations (ok) or if you use Control Tower it has an account factory. The advantage of Control Tower is it puts all kinds of best practice security in place for you. This disadvantage is it takes an hour to create a new AWS account as it has to roll out all the controls to each new account.
I would suggest the best solution is to write your application to service multiple customers through one account / VPC / IP if your clients can do that. Use some kind of authentication / authorisation service to ensure requests are associated with the correct customer.