Very probably if you can't think how it would be beneficial for your use case, it won't be beneficial to your use case.

"Website" (as opposed to "web app") sounds like something static with no server-side logic (save serving up static content) which further makes Docker not seem very useful for your use case. In your shoes, if I haven't inferred too much, I'd probably first think of some CloudFront/S3-based solution.

Typically, Docker is used in cloud infrastructure (AWS or the like) in situations where there's a lot of server-side resource usage and you want to be able to scale up on very short notice. It can also be useful for on-prem sort of situations, or for if you want to run server-side software in a "contained" sort of way where you don't have to install your software's dependencies on the host machine. (Running a Java app on an EC2 node without installing a JRE on the instance, for instance.) Docker is also good (particularly relative to PaaS options) for minimizing vendor lockin (though, again, only really if you have server-side logic to contend with, and if you're dealing with a static website, it's hard to imagine vendor lockin being an issue.)

I suppose you could shoehorn it in. Stick your static website on an EC2 node with a Dockerized Nginx to serve it, or even bundle your static website into a Docker image, but I'd imagine you'd pay more for such a solution than just using CloudFront with S3 or whatever.

(And yes, I keep mentioning AWS, but there are lots of hosts out there. For the more focused LAMP-stack-providers rather than IaaS options, Docker would be of even less use.)

Now, even if you do intend to have server-side logic, I'm not sure Docker really adds much to the conversation unless your server side logic is expected to use a fair bit of CPU and/or RAM, you're expecting to get a good amount of request volume, and you want to be able to scale horizontally very quickly.