The natural conclusion is that MAX_STATEMENT_TIME forces MariaDB to send the results it read until now, without any error. But this is not true:

I don't think it's a natural conclusion (assumption) at all. How would this work in general, if it were a normal SELECT, which was caught by the timeout on the phase of query optimization, or DDL in the middle of the operation, etc.?
SELECT returning an empty result (or partial result set) would be a disaster, because the end user wouldn't know whether it's the real result set or not. DDL which leaves things "as they are" in the middle of the operation would be even more of a disaster.

The description of the variable also clearly says that the operation is aborted:
https://mariadb.com/kb/en/mariadb/server-system-variables/#max_statement_time

Description: Maximum time in seconds that a query can execute before being aborted. This includes all queries, not just SELECT statements, but excludes statements in stored procedures.

Re-opening the bug – sorry, I've misread the initial complain, which is about SLEEP not producing the error. The previous comment is still true, of course max_statement_time is not meant to make a query return intermediate results.

For SELECT SLEEP(N), it works the same way as if you interrupted the query manually – that is, if you run SELECT SLEEP(10) in one connection, and while it's sleeping, run KILL QUERY n, where n is the first connection's ID, from another connection, SLEEP will also return 1 rather then ERROR 1969. That's how SLEEP function is defined:
http://dev.mysql.com/doc/refman/5.5/en/miscellaneous-functions.html#function_sleep

When SLEEP() is the only thing invoked by a query that is interrupted, it returns 1 and the query itself returns no error.