Attacking the kernel via its command line

The topic is verified boot, not users exposing themselves to additional attack surface by using new features. In terms of impact on verified boot security, it doesn't matter whether you use the features. It only matters that the verified OS code supports those features via the persistent state. It doesn't support persistent privileged code (i.e. the persistent state is not trusted much) which is why it has a good / useful verified boot implementation, but not a fantastic one.

Look back at the context:

> 9) firmware / bootloaders / kernel / base OS / privileged code / data trusted by privileged code / all code / all data trusted by code
> This would be ChromeOS if it didn't have extensions, apps and Android app support.

I only stated that it would be a stronger implementation of verified boot without any persistent code.

Persistent data without supporting persistent code would mean an attacker's persistence mechanism doesn't start off with (sandboxed) code execution.