Is it a list of allowed ciphers stored at the client side?
This list is defined by the application or more likely the implementation. Basically what you do with "False Start" is that you run a normal TLS handshake and if all of the conditions you found are met, you also immediately start sending encrypted application data - before you have finished the authentication with the server, ie awaited his
ChangeCipherSpec. Because you wait for the third message run before making your decision, this means the cipher suite has already been negotiated and thus you can apply your white-listing strategy.
How is this different from the client's ciphersuite list?
Indeed, these two lists may be identitical but the RFC explicitely states that you want strong security with the picked cipher suite if you want to use "False Start". Now consider what this requirement means: You cannot possibly connect to servers which only support cipher suites you consider "potentially weak", the RFC mentions RSA key-transport as an example for that. So if you'd make these lists equal, yoo wouldn't be able to connect to those servers which is usually undesirable.
For your last question, consider this quote from the RFC:
Instead, the security goal is to ensure that if anyone at all can
decrypt the application data sent in a False Start, it must be the
Basically you want to make sure that if you are under attack and you used "False Start", an attacker can't learn anything about the application data, which is why you want to be "extra-confident" in the cipher-suite.