In older issues about the Sieve system I find comments by ludovic of this sort:
-- "You shouldn't manipulate Sieve scripts behind SOGo's back."

This, in my opinion, shows a weird design error in the way SOGo treats Sieve.

Sieve consists of a server and a client (e.g. SOGo). However, SOGo kind of behaves as if it is a Sieve server, even though it is a client.
My intention is not to say SOGo's functionality is wrong. I'm saying that the implementation is incorrectly executed. What SOGo currently does is server behaviour in a client.
It should either behave as a client, or it should implement a sieve server itself. It just should not connect to a server as a client, then disregard the server itself entirely, and just push its own sieves.

The biggest issue that arises is this:

If a user changes his sieve on the server, using a sieve client that is not SOGo (e.g. Thunderbird, gsieve), SOGo will blindly revert that change. That is not client behaviour. The client should accept that the server is leading, and that it is not the only client that may connect to the server (otherwise the client server architecture is meaningless)

Currently the workaround is to disable the Sieve functionality in SOGo, that way every Sieve client will work except SOGo, otherwise, no Sieve-client works, except SOGo.

Personally I think it would require the least work if SOGo worked as a pure client, and played nice with other Sieve clients. However it would be good as well if SOGo implemented a Sieve server, and let other clients connect to modify the sieves.

I don't expect this change to come quickly (or at all), but I would expect the SOGo developers to give this some serious consideration, since the current behaviour is (in my opinion) ugly and hackish, by using a client-server protocol the wrong way around.

Note: I do not have any problems with SOGo features such as automatically disabling vacation auto-replies, because in doing this SOGo correctly functions as a Sieve client.