If you read previous comments, specifically the commit comment for the upstream revision, you'll see that it was an intentionally introduced limitation. My guess is that's what the InnoDB team had to come up with in order to fix the recovery crash without making too intrusive changes in a post-GA version.
The workaround should be to shutdown the server gracefully, increase the value of innodb_log_file_size to make it definitely greater than 10x(total blog length), and to start the server again.

That said, it looks like in InnoDB 5.6.22 the limitation is a bit relaxed (although not completely removed like in 5.7). InnoDB 5.6.22 will most likely be in 10.0.16 – doubt it will make it to 10.0.15 since 5.6.22 has not been released yet..

The upstream bug they were solving is http://bugs.mysql.com/bug.php?id=69477

Is there a chance to get back to 10.0.13 (with debian/ubuntu repository?) or is the bug in there to?

You can find 10.0.13 in the repo, e.g. ftp://ftp.osuosl.org/pub/mariadb/mariadb-10.0.13/repo/ (the repo that you are using is likely to have a similar path).
But really, increasing the value of innodb_log_file_size is much simpler, and it's the right thing to do anyway if you have big blobs, otherwise your server is potentially affected by bug#69477 which might cause real damage.

which log_file_size should we set?
we have blobs which might be over 100MB...

The max allowed value for innodb_log_file_size is 512GB / innodb_log_files_in_group , so you have enough room for the maneuver.
Big redo files might make crash recover slower, but since your crash recovery is affected by the bug anyway, it shouldn't be a critical reason not to increase them.