Probably that value is read at container build time to change a service definition. It would likely require some reworking so that it’s read at runtime.

That's what my analysis showed. I was going to try to create a simple fix and just submit a PR but it looks like the way to solve it likely involves storing the value in parameters and referencing it at runtime when attempting to send mail instead.

I have not been able to disable/enable mail delivery with Env vars on a project with Symfony 4.3.4
file .env

SWIFTMAILER_DISABLE_DELIVERY=1

file config/packages/swiftmailer.yml

swiftmailer:
    disable_delivery: '%mailer_disable_delivery%'  

file config/services.yml

parameters:
    swiftmailer_disable_delivery: "%env(bool:SWIFTMAILER_DISABLE_DELIVERY)%"

This config does not work.
Even if calling $container->getParameter('swiftmailer_disable_delivery') return the correct value regarding the env vars.
When processing config, the swiftmailer bundle always consider that this value is true (as it is a string whose content is "%env...", see https://github.com/symfony/swiftmailer-bundle/blob/master/DependencyInjection/SwiftmailerExtension.php#L83.)

I solved the problem in creating the parameter in a php file( and removing the parameter from services.yml).

file config/services.php

<?php
$container->setParameter('swiftmailer_disable_delivery', (bool)getenv('SWIFTMAILER_DISABLE_DELIVERY'));

This require to clear the cache.
An other solution would be to create a good old file called "parameters.yml" that would not be commited (in addition to the also uncommited ".env.local" file).

Closing as this bundle is not maintained anymore.