Fair enough, but when they are not communicating the same thing, there are no grounds for objecting to them on the basis of redundancy.
The problem with notification only of failure is that one is left uncertain about success, though I would agree that striking a balance between distraction and uncertainty is difficult.
It also would mean you would move the item eagerly, then put it back on error. Or alternatively make it a "ghost" item in the list then remove on success. But overall the eager-move + toast + undo is just a much faster feeling implementation and the overall UX is so much cleaner.
The undo button justifies the toast here IMO. Otherwise I'd prefer ghosting really.
For the checkboxes, I'd say GitHub nailed it: for settings that are applied instantly (e. g. https://github.com/settings/appearance), they show a spinner and then a single checkmark right across the section title. (It used to be next to the input element – both ways are fine, I think)
I agree they do a good job, but I think a toast without undo could also work there. Apply the UI eagerly, toast success or failure. As it is, I assume on failure it becomes an 'X' and shows an error? I just dont generally like very short transitions like the spinner is currently. In general, coming from app land, I prefer a deferred loading spinner that only shows if the action takes X ms. So in the happy path of a fast action the user never sees the loading state.
That's the problem of whether the developer and the user have the same expectation of the max duration or timeout of an action. For example a developer might default all backend actions to have a timeout of 30 seconds. But as a user, if the action succeeds quickly (the usual case) I want to immediately see a confirmation of that. I don't want to wait 30 seconds just to see no notification about any failure.
