I don't see why it is a regression, why it is a critical and why it is a bug.
Reducing priority and switching to a task. I'll keep the original summary though because I just don't get it.

It's a regression because before the patch one can start a server without taking binary logs and activate them later on without restarting.
After the patch i can't see a way of doing this, may be i miss education here. If a patch cancel the usage of drop table, would it be a bug or a task ? Someone can also complain that drop table is dangerous and should be remove. Fortunately someone clever decided that there could be granted permission for this action. So having special grants would be a solution as well as having different variables to disable binlog global or per session. So it's already humiliating that famous blogger and partner blog post was first picked up by MySQL, but that we simply merging it without thinking of a proper design that take into account where MariaDB should stay in regard to dynamic setting of variables and for online operations.

It's a regression because before the patch one can start a server without taking binary logs and activate them later on without restarting.

No, one couldn't. By changing the value of SQL_LOG_BIN one could disable binary logging if it was activated at startup (and then enable again), but If binary log wasn't enabled at startup, sql_log_bin had no effect, either global or session.
Please try, and if you manage to enable the binary log at runtime, please paste the output of how you did it. Here is mine, of MariaDB 5.5.40.

MariaDB [test]> select @@log_bin;
+-----------+
| @@log_bin |
+-----------+
|         0 |
+-----------+
1 row in set (0.00 sec)

MariaDB [test]> set sql_log_bin=1;
Query OK, 0 rows affected (0.00 sec)

MariaDB [test]> create table t1 (i int);
Query OK, 0 rows affected (0.38 sec)

MariaDB [test]> show binary logs;
ERROR 1381 (HY000): You are not using binary logging
MariaDB [test]> 
MariaDB [test]> set global sql_log_bin=1;
Query OK, 0 rows affected (0.00 sec)

MariaDB [test]> create table t2 (i int);
Query OK, 0 rows affected (0.25 sec)

MariaDB [test]> show binary logs;
ERROR 1381 (HY000): You are not using binary logging
MariaDB [test]> exit
Bye

elenst@wheezy-64:/data/releases/mariadb-5.5.40-linux-x86_64$ ml test
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 2
Server version: 5.5.40-MariaDB MariaDB Server

Copyright (c) 2000, 2015, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [test]> select @@log_bin, @@global.log_bin, @@sql_log_bin, @@global.sql_log_bin;
+-----------+------------------+---------------+----------------------+
| @@log_bin | @@global.log_bin | @@sql_log_bin | @@global.sql_log_bin |
+-----------+------------------+---------------+----------------------+
|         0 |                0 |             1 |                    1 |
+-----------+------------------+---------------+----------------------+
1 row in set (0.00 sec)

MariaDB [test]> create table t3 (i int);
Query OK, 0 rows affected (0.28 sec)

MariaDB [test]> show binary logs;
ERROR 1381 (HY000): You are not using binary logging
MariaDB [test]> exit

Yes correct, i'm taking about the possibility to
activate binlog in the configuration file and an init_scipt with set global sql_log_bin=0;

Such default allow me to activate the binlog on demand like for example if a slave should become a master in any slave promotion tool.

I see.
It sounds like a scary approach, so I'm not quite sure it's such a bad thing that people can't do it anymore.
Anyway, the request stays open and will be considered.

I quite like Jeremy's thoughts on global sql_log_bin that it should be only a session thing and Oracle have made it so in 5.7
http://blog.jcole.us/2014/08/08/stupid-and-dangerous-set-global-sql_log_bin / http://blog.jcole.us/2014/12/04/thanks-oracle-for-fixing-the-stupid-and-dangerous-set-global-sql_log_bin/

Having log_bin as global wr sounds like a fair idea.

conceptually this is possible.

mysql_mutex_lock(&LOCK_log);
if var=off {
mysql_bin_log.close(LOG_CLOSE_STOP_EVENT|LOG_CLOSE_INDEX)
} else {
mysql_bin_log.open(var, LOG_BIN, 0,
                                        WRITE_CACHE, max_binlog_size, 0, TRUE)
}
mysql_mutex_unlock(&LOCK_log);

There of course a lot of calls to mysql_bin_log.is_open (volatile log_state!=CLOSED) doing extra work for binary logging without any locking. Even MYSQL_BIN_LOG::write checks is_open before acquiring LOCK_LOG.

At least one is_open call is in DBUG_ASSERT. It would be a fairly big undertaking to ensure that these paths return safely after disabling/enabling or changing the variable log_bin.

Such a feature would be a great differentiator for mariadb in the sense of having multi tier replication setups and being able to promote slaves on the fly without restarting them.

 MDEV-6555 seems sql_log_bin isn't global any more.

Having log_bin change having an effect once flush logs are issued seems like a fair way to not too intrusively introduce this. I'm assuming there's sufficient locking around that implementation.