That's a good point.
There are actually multiple places where we don't currently use a custom dialog. GitHub search isn't very helpful to find them but here's the list built locally:
confirm():
https://github.com/flarum/core/blob/v1.0.0/js/src/forum/utils/DiscussionControls.js#L239 (delete discussion permanently)
https://github.com/flarum/core/blob/v1.0.0/js/src/admin/components/EditGroupModal.js#L151 (delete group)
https://github.com/flarum/core/blob/v1.0.0/js/src/admin/components/ExtensionPage.js#L144 (uninstall/rollback extension)
https://github.com/flarum/core/blob/v1.0.0/js/src/forum/components/IndexPage.js#L320 (mark all as read)
https://github.com/flarum/core/blob/v1.0.0/js/src/forum/states/ComposerState.js#L217 (close composer)
https://github.com/flarum/core/blob/v1.0.0/js/src/forum/utils/PostControls.js#L153 (hide post)
https://github.com/flarum/core/blob/v1.0.0/js/src/forum/utils/PostControls.js#L176 (permanently delete post)
https://github.com/flarum/core/blob/v1.0.0/js/src/forum/utils/UserControls.js#L102 (delete user)
alert():
https://github.com/flarum/core/blob/v1.0.0/js/src/admin/components/AppearancePage.js#L114 (entering an invalid color in admin)
We could just have a generic AlertModal or ConfirmModal component that can be re-used but I think that would encourage bad practices in case an extension wants to customize just one of them. The ideal solution would be to have one component for each situation.
Using native browser confirm/alert has the benefit of clearly stopping the application flow and possibly better integration with assistive technologies than a custom thing.
The "mark as read" situation does feel a bit different because unlike the other actions it's not a critical warning before deletion of data. But it's still an important warning because it can't be undone.
There is some discussion about a different way to handle the "mark as read" situation in flarum/core878 and flarum/core1915 where we talk about removing the confirmation and making the action cancellable instead.