I'd go even further and say that modals make sense in almost any context where there's some underlying state whether it's a game, form, or even just scroll position in a forum thread.
And I don't see why the modal needs to be limited to quick jobs like inline edits. It could be the place where the bulk of the tasks are done.
Modals done well can remove anxiety and uncertainty from the user.
One example that comes to mind having just bought plane tickets is that the plane ticket flow could be an underlying all-on-one-page UI (flight -> seats -> payment) where each section opens as a form modal on top of that state. You can close modals, open previous sections, edit completed sections, where the modals communicated that you're not losing state by navigating between forms. One of the best UX aspects of the modal is seeing the underlying state behind it and behind able to click out of the modal to return to it.
Meanwhile, when buying tickets 30 min ago, the airline website had a sequence of pages where, I found out, going back to make an edit on a previous page reset the state of the subsequent pages. Obviously they could improve that without modals, but modals communicate state preservation by their nature.
Modals get too much hate just because they can be done poorly. Most UX is done poorly and that's not a reason to wash your hands of it.
Your example doesn’t suffer from, for example, not being able to bookmark a step in the booking process. At the end of the article, “forms to update/create entities” is specifically mentioned as a valid use case.
I was pointing out that a booking funnel is not a place where this is necessarily a bad pattern, and this is already covered in the article. Their framing is that you should avoid modals for "resources", but it's fine for "forms that update/create entities". So that example is not in disagreement with their position.
This is one of my main points: good UX takes some thought. It's harder than doing the bare minimum. In this case, preserving someone's post in a <textarea> is the same concern whether it's in a modal or stuck at the bottom of the page. Neither using a modal nor not using a modal solve this for you.
It usually makes sense to introduce a localstorage draft system regardless of where the <textarea> appears on a forum.
And I don't see why the modal needs to be limited to quick jobs like inline edits. It could be the place where the bulk of the tasks are done.
Modals done well can remove anxiety and uncertainty from the user.
One example that comes to mind having just bought plane tickets is that the plane ticket flow could be an underlying all-on-one-page UI (flight -> seats -> payment) where each section opens as a form modal on top of that state. You can close modals, open previous sections, edit completed sections, where the modals communicated that you're not losing state by navigating between forms. One of the best UX aspects of the modal is seeing the underlying state behind it and behind able to click out of the modal to return to it.
Meanwhile, when buying tickets 30 min ago, the airline website had a sequence of pages where, I found out, going back to make an edit on a previous page reset the state of the subsequent pages. Obviously they could improve that without modals, but modals communicate state preservation by their nature.
Modals get too much hate just because they can be done poorly. Most UX is done poorly and that's not a reason to wash your hands of it.