Pardon if I am being slow, but does OP_EVAL allow for crafting new and wonderful transaction type through RPC ?
I thought that every new exotic transaction implemented by this way will still require one to implement it in the code and compile...
No, OP_EVAL allows the person paying to pay the recipient (who has provided the address) by any transaction type imaginable. That is, even without any support for the particular transaction type in the payer's wallet. That's because OP_EVAL makes it unnecessary for the wallet software to understand the output.
It also improves decentralization, since there will be no need to coordinate assignment of address version numbers. (And there are only 256 address version numbers to assign -- too few to cover all scripts.)
Quite frankly, the implications of having more than 10 (let alone more than 256) distinct transaction types, each with unique "quirks" in operation, are disturbing.
The GUI will end up being like a fighter jet cockpit, for one.
I'd still like to have at least two distinct address forms, one for "simpleton" transactions (like what we have now), another for everything else, just to make demarcation between "basic" functionality and "advanced user features" more explicit. Because you know, people have trouble grokking Paypal interface (and bitcoin GUI), and having them away from getting involved with complicated 5-party signing schemes until they really know what they are doing would be wise.
Because OP_EVAL encodes the transaction type in the address itself, no-one ever needs to receive transaction types they don't support. So wallet software can pick and choose. With OP_EVAL the wallet software creator is free to choose which transactions it can handle and ignore others (because, well, you just won't give out any addresses for transactions you don't support).
Important thing to note here is the separation of wallet and node. Node needs to be able to handle the scripts of any transactions that are possible. However, wallet software doesn't have this need.