Value Objects are classes that represent more than simply an integer value or a string value. They have no identity, as in $10 or “cat”. Some argue that value objects should not be used in commands and events. However, I don't see why not.

Events are classes that represent things that happened. Optimally, DDD/CQRS/ES systems should not be CRUD systems, so events are usually more meaningful than “NameChanged”. Many argue that only the heart of an application that represents real domain knowledge should be build using DDD/CQRS/ES, and that it is overkill for CRUD applications. Some funcionalities ES gives us out of the box are

• automatic logging of everything that happened
• automatic ability to denormalize into any optimized read model - synchronously and asynchronously
• optimizing application responsiveness due to the separation of reads and writes and the asynchronous nature of writing optimized read models
• ability to simply add or change read models
• messaging - pushing events to a message bus, thus allowing for message driven processes to be built on top of the application, or simply reacting to events asynchronously and reliably, such as sending emails

Building DDD/CQRS/ES applications really isn't that much more complicated or involved as building CRUD applications. On top of that, as soon as a CRUD application becomes a little more complex and has more and more requirements, a CRUD architecture becomes very limiting very soon. Adding things such as logging, optimized read models, messaging, (semi-) automated processes, etc. to a CRUD application will be extremely cumbersome and sub-optimal. In my opinion, you may as well go straight to the DDD/CQRS/ES architecture. I do see the value of CRUD for simple bounded contexts such as tenant and licensing management - parts of the application that do not change much and that do not require most of the above functionalities.