OOUI has a custom Exception class that is thrown in a handful of places. All those places use this exception type as an unchecked exception, meaning callers must not catch it, but instead avoid it in the first place (for example, in HtmlSnippet, by making sure that the argument is of the required type). However, unchecked exceptions should inherit from SPL exceptions (LogicException & RuntimeException), as documented in https://w.wiki/6nur. Amongst other things, this allows static analysis tools (like PHPStorm and phan) to categorize the exception and set expectations such as «Should the exception be documented using @throws?» or «Should callers be catching this exception?».
However, reparenting the OOUI\Exception class is not convenient: different SPL exceptions would make sense in different places. For example, sometimes it's InvalidArgumentException, other times it could be UnexpectedValueException, etc. So, it would be easier to just ditch the custom OOUI\Exception class, and throw SPL exceptions directly. This prevents PHPStorm from complaining about missing @throws, as well as randomly adding them when refactoring code. And it will help avoiding spurious phan issues when T338426 is resolved.
There's an argument to be made of whether this can be considered a deprecation change. Unchecked exceptions (unlike their checked siblings) are implementation details and not part of a method's contract: callers should make sure to avoid the exception in the first place, so it should not matter to them what exception class is used. On the other hand, we didn't have a formal exception handling policy until T321683 (last year), so not everyone may be familiar with it. Nonetheless, it's reassuring that all usages known to codesearch are IDE-added @throws tags that are wrong and should be removed.
Finally, a special mention goes to the one place where OOUI\Exception is caught: in OOUI's Tag::__toString. Here I need to add a bit of history. Before PHP 7.4, it was not possible to throw exceptions from within __toString methods. If you did that, PHP would just fatal and catch fire: https://3v4l.org/s5Fkk. To work around this limitation, r174834 (in 2014) moved the existing __toString logic to a helper method, and made the real __toString emit E_USER_ERROR instead of throwing any exceptions directly. The end result is roughly the same. Nowadays we only support PHP >= 7.4 (and soon it's going to be >= 8.1), so this workaround is no longer needed. Therefore, we can just drop the custom exception-catching logic, and just let any exception bubble up from __toString.