Viewmodel one-off events: can we agree this is a bad article?

Referring to this article:

https://medium.com/androiddevelopers/viewmodel-one-off-event-antipatterns-16a1da869b95

I fail to see the point.

Using a buffer/replay for underlivered events (in case the user backgrounds the app) makes the likelihood of this event not being collected very, very small - and we are not talking about mission critical apps in 99% of the cases.

Modeling a bunch of "this event happened" inside a state class seems very ugly to me, and then it has an added cost of having to nullify them, every single one, after it has been collected.

It also makes it confusing and hard to reason about a UI state when it has "this event happened" properties inside. When I see

`val paymentResult: PaymentResult? = null`

I would naturally think of this meaning there is a need to display a new composable with info about this result, and *NOT* the need to launch a new launched effect, then nullify the corresponding property in the viewmodel.

A similar one is given by the Android docs:

data class LoginUiState(
    val isLoading: Boolean = false,
    val errorMessage: String? = null,
    val isUserLoggedIn: Boolean = false
)

Am I the only one who finds this unintuitive? We are modeling specifically the UI *BEFORE* the user is logged in, with either a loader or an error, so what is the point of a `isUserLoggedIn` flag since the UI state for a logged in user is a different one?

Is anyone else of the same/opposite opinion? Obviously it is best practice to minimize events when possible, but I much rather have a single collector for events separated out from state.