I don't follow the reasoning here. Why does the onus lie on the web developer and not on Google or Apple?
The web dev's responsibility here (or possibly his manager's) is on deciding what level of support they're going to give for those outdated devices.
Do Apple/Google/etc also bear some responsibility here? Absolutely. They can (and should imo) support older devices, much more than they do. But they're gonna chase profit, and at some point the costs of that support outweigh the benefit. That's just another hard fact of life on the web, one that developers should take into account when deciding what kind of support they want to give to outdated browsers with their code.
Luckily, for most things down-compiling to something like ES5 isn't incredibly difficult and can be automated.
It can be argued that browser vendors ought to do their best to align with standards, while simultaneously arguing that old devices do exist in the wild and some amount of onus falls on web developers to cater to segments above some threshold of usage.
Because you can easily support newer JS features in older browsers with Babel? https://babeljs.io/docs/en/index.html. 8-14% of your users probably have something that will not work with the latest-greatest JS features it is your choice as a developer to not support them.
Regressions are regressions. You don't get to make excuses if you unilaterally changed something for someone.
This is a common thing when working on library-like-things outside the web too. Widely used C++ libraries generally aren't taking hard dependencies on C++20 features right now without continuing to support e.g. C++11/14/17.
Don't you think the customer experience is strictly more important than the developer experience?
The developer is putting in the hard yards to make the website for their community event. Why shouldn't the user make the effort to have a web browser that's updated to 2022?
It's a complex conversation, but "the customer is always right" is not always the case.
The developers do have access to statistic about exactly how many clients they'll break. They might have felt that it's so few that the ease of development justifed breaking the website for just a few users. They could tell them that their browser is too old, saving many a lot of headache.
In this case, the problem, making a reservation to volunteer, is simple enough that you could have solved it with a CGI script in 2001, and it would still work. So it only broken, because someone felt it needed to be more modern. Remember, this is people who volunteer their time, they're not forced to do anything, so you have to be as accommodating as possible.
In fact, browsers that are more than X months old should automatically pop up a warning telling the user that it hasn't been updated recently and they're running a security risk by continuing to use it, including/especially on these old EOL devices. Browsers that have reached this point shouldn't be expected to be supported by websites.
Optional chaining however is missing for something like 8% of users https://caniuse.com/?search=optional%20chaining so for this specific situation I'd say that's probably a bit too high to not transpile/have a fallback for most anything but a tech demo.
Web developers should be considerate in case people don't or can't update their browsers.
Google and Apple should make sure their systems are up to date.
If it doesn't work, both are to blame, and should both do something instead of blaming each other while the user suffers.
Why have new features if it is not to use them? Consider them a preview, as in "this is what users will have in 5 years", or use something like Babel. Personally, if possible, I like to target 10 year old devices, more if the cost is low. It may seem crazy but I think that now, 10 years is a reasonable lifespan for a computer, including phones and tablets, 15 for a desktop PC or a good laptop.
It's one thing to require async/await: transpiling async->generators->regenerator turns into loads of ugly/inefficient code. But optional chaining saves a couple dozen characters, and if the developer really wanted it they could add a very simple babel transform.
Having seen code break over this exact thing before, I'm almost certain that the developer was unaware they were breaking anything for anyone.