If I had to be and admin of mixture of linux distributions I would
probably use 'service', instead of remembering all commands suited for
different init flavours and checking on which box I'm about to run a
command.

But in such a case I probably would not care what kind of init
subsystem is running on my box. I would not wait for Devuan to get
something with sysvinit.

So if I'm stick to sysvinit why I am to use 'service'? Why learn
another wrapper name which does one thing more if I can always do

env /etc/init.d/blabla start

If I want to have clean environment when starting this script.

But I cannot imagine why should I even use 'env' command (in ideal
world). The init script should use it if it is important that the
environment is cleaned up before starting the application daemon ( or
service if you want to call it this way). This is responsibility of
application maintainer to provide 'idiot proof' starting script. The
assumption that 'service' command will prepare environment is IMHO a
mistake, cause the init script _can_ be executed directly as it was
done for a long time, before 'service' command was introduced.

Yes, I think it was bad design decision to make 'service' command to
cleanup environment, not leaving this task to init script, because of
legacy of /etc/init.d , and because the init.d scripts can be
executed directly anyway.

If 'service' command was running scripts from other
folder/schema/subsystem, but not from well known /etc/init.d, than I
would say I should obey the rules of the new command, once decided i
want to use it.

So, please make the system suit your needs, but do not assume what are mine. :)

--
regards
piotr