The writeapi permission controls whether one is allowed to use action API endpoints which do some kind of write. This is not terribly useful:
- By default it's given to all users, even anonymous ones.
- Write permission handling is somewhat mixed up with write performance handling (ie. whether the API does DB writes) and as a result all kinds of conceptually non-write APIs require this permission.
- Specifically, the login API requires it, so revoking it from anonymous users makes the site unusable unless it uses some very atypical authentication method.
- All actions that actually change something have their own user rights so writeapi isn't really needed for access control.
- writeapi check are applied at the API endpoints, so usually they can be circumvented by performing the same action via the web interface.
Requiring writeapi for login is a recent change (T283394: ApiLogin and ApiClientLogin should return true for isWriteMode()) necessitated by the coupling of write permission flags and write performance flags. A bunch of third-party wikis disabled writeapi for anonymous users; there is not much point to that, but the documentation kind of implied it's a useful thing to do (e.g. here) and it didn't break anything. But with the change to login APIs, it does break a lot of things, so let's get rid of it and turn Rest\Handler::isWriteAllowed() and similar into performance-only flags.
A possible counterargument would be that those flags come in pairs (e.g. with Rest\Handler::isReadAllowed()) and the read flag is meaningful for permission handling - there is no readapi right, just read, and that is used as the main access control mechanism for all kinds of things. So having those flags fulfill different functions would be unintuitive.