As I stumbled over that use case already several times...
If I have my application and we can assume that it is a web application where I have to run some console scripts, probably as cronjob and additional I am working with messages that I need workers. So assume this is my setup.
When I am writing now logs in my application it would be useful what runtime mode caused my log entry (assume we have e.g. an unhandled exception). So was it a cli, web or a worker? Some logging systems works with json data and it would be useful to add that data with a processor, e.g. cli, web, cliworker or webworker. Later I could filter on my log entries for that. When I am writing just a logfile it could be usefull when I have different files, e.g. prod_cli-2024-05-24.log, prod_web-2024-05-24.log, prod_cliworker-2024-05-24.log, prod_webworker-2024-05-24.log as rotating files or just as simple stream e.g. prod_cli.log. So I would need a handler for it which can rotate or not (maybe configurable option rotate:true|false).
For implementation I could use the kernel parameters which contains already information about the runtime mode.
If just the options are added to the bridge, it's up to everyone to use it or not when configuring the logging for symfony.