The CRUD interface I created for my new app. Creates, updates, deletes, reads and lists
Ad 1) it Is ok to pass id in the Array data of you want to change the id. If you were asking if you can omit the id argument. Then yes but you Will never be able to change id And honestly it becomes more verbose to use. And honestly it Is quite premature to expect this on this generic level.

Ad 2) if "wrong" means empty id or database unreachable and similar, then yes, throw (or pass up) exceptions. But if it means object with given id not found then return null, it is not exceptional to ask for non-existent id, it just leads to a different result. But when database is unreachable, you are unable to say wheteher it exists or not and if it does what are its data and so here exception is appropriate.

Although many will argue here that exceptions are better. I think that exceptions are there to halt program (and do cleanup and notify someone) when something went really bad, not to be used to control flow of your program.

Ad 3) You have (at least) 2 options here:

Dont make it part of the interface. Let implementations take care of this. Could be abstrakt but in generál i advise against abstract classes as they sooner or later start cousing troubles when an implementation wants something done slightly differently And nobody thought about it when the abstract class was designed.

Or,

if it is / has to be part of the interface than it might better return error messages/codes instead of just bool. And the caller should be responsible for calling it first, if He does not call IT than the interface Is being used incorrectly And anything can happen, but that would be a dev's Mistake.

To provide an analogy, it would be like calling Iterator::current() before making sure Iterator::valid() returned true -> undefined behaviour, anything can happen, exception thrown, or nothing, or random element returned, or anything else - simply whatever was the most convenient for that implementation, anyway it is not important because at that point the interface is being misused and the code calling it is wrong and need to be fixed.

Calling it from inside the other method (valid from current, or validateData from create/update) just to make sure that the first method returns true and throw exception otherwise is also wrong because it will get called twice (redundantly) for whoever used the interface correctly. 

Although many (especialy PHP) devs may argue that it is better to always throw exception to make sure the dev notices this as soon as possible. I personaly think that you should just write it into the interface's doc comments to state very explicitly that calling create/update without validating the data first is undefined behaviour. How many consumer classes will there be for CrudInterface anyway? One? Two? You make sure that these are correct and then everyone is going to use them, right? So...