MariaDB [test]> create table t (a int) partition by hash(a) (partition p1 encrypted= "i will think about it");

Query OK, 0 rows affected (0.034 sec)

MariaDB [test]> create or replace table t (a int) partition by hash(a) (partition p1 encrypted= 42);

Query OK, 0 rows affected (0.062 sec)

On the table level both would have thrown ER_BAD_OPTION_VALUE.

The practical side of the problem is that values which look meaningful but are in fact incorrect may bypass validation.
For example, on a server without configured encryption, both of

create table t (a int) encrypted=yes;

create table t (a int) encrypted=1;

will fail – the first one with ER_CANT_CREATE_TABLE and a bunch of warnings, because there is no encryption available, and the second one with ER_BAD_OPTION_VALUE because "1" is in fact not a valid value.
However, with the same options on the partition level

create table t (a int) partition by hash(a) (partition p0 encrypted=yes);

create table t (a int) partition by hash(a) (partition p0 encrypted=1);

the first one will again fail with ER_CANT_CREATE_TABLE, but the second one will work, giving the impression that an encrypted partition has been created.