Since diogomonicapt didn't answer i'll try to give an ELI5 answer ;)

Docker-containers have many advantages, but one of the big drawbacks until now was that it was really hard to pass secrets into them. Imagine you are a simple, stupid Java-container. You handle HTTP-Request and need to access other services like Databases in order to function. In order to connect to the postgres-instance you need to know 3 things: the URL, the database-name and a password. Getting the URL and the database name is easy, just pass them via environment-variables. The tricky thing is how to pass the secret. Environment variables are not encrypted and super easy to read as soon as you have gained access to the container. There were some solutions, but they were complicated. So most just passed them via env-variables. Huge security risk. Very bad.

This solves the problem.

If the environment is super easy to read when you have gained access to the container, so is a filesystem... The use of secrets is more to transmit secrets to the container without giving it to people.

The problem is applications unintentionally leaking the ENV. Think a hoptoad exception that attaches the current ENV to the report that sends up to the remote server.

Or think about you exec'ing imagemagik and now the process running potentially adversarial code also has access to your parent's env.

Or think about an application crashing and doing an unintentional core dump to disk.

Way better than I could have answered ;)

Probably they were concerned that users have to store the secrets (certificates, etc...) in the container filesystem - or mount/share the location on the host were the certificate for a specific app is present. Probably there are more ways to do it, but also probably none is end-to-end secure.

With this you can securely store the certificates; takes away the developer's responsibility of taking care of managing and distributing them to their apps, swarm will take care of that in a secure end-to-end fashion.