Under normal circumstances not many events are directed into the bad streams at all - which is ultimately the reasoning behind wanting to slim them down and reduce cost.
For context: if a company runs pipelines in two primary regions (which ours does), two environments (which ours does), runs the s3 sink process (which adds another stream), and all non-“good” streams are sharded to 1 (the minimum):
4 underutilized streams per pipeline (collector bad, enricher bad, pii, sink bad) * 2 environments * 2 regions * $11/mo * 12 mo = >$2000 per year.
I do agree that this figure is completely trivial for larger production pipelines. Our larger pipelines are over 100 shards each, and the $ of one shard here is laughable. For staging/development environments however, this is unnecessary cost. For smaller companies, cutting monthly operational cost in half is almost mandatory. Unnecessarily spending >$250/year (prod env only) or >$500/year (prod and stage envs) probably won’t happen.
Regarding filesystem - I already have Fluentbit sitting on all machines forwarding logs to a centralized stream, and then on to other tooling (elasticsearch, graylog). If “bad” was logged, it would be easy to point the forwarder at the log and not worry too much about filesystems being potentially unreliable.