If your app exhausts the generous 160G/mo in free-tier bandwidth, yes, you’d have to pay up. Though, Fly does send an email when it detects abnormally high bandwidth use. So, you’ll probably not end up with a huge surprise bill. Fly also runs some form of rudimentary DDoS shield across its edge, so it isn’t like a bot is going to have a field day. Even if it did, Fly probably refunds you for your troubles.
If your app is publicly accessible, this is a potential problem, yes. At the cost of some latency, you can choose to front your web server (ie HTTP/S-only) on Fly behind cloudflared and add rate limit rules (which are completely unmetered as of this month, while DDoS has always been free).
Yet another alternative is to run private Fly apps with no exposed public IP (which more or less have unmetered bandwidth as long as traffic stays within 6pn, Fly’s WireGuard backhaul).
Yet another is to guard a public-facing app with some form of auth (ex: HTTP basic auth).
Besides, one can always bake in admission control themselves for the runtime / language / server / image they deploy.