If you need to validate data it might be a good idea to keep the validation as close as possible to the data. If a string comes in that represents a VIN number, wrap it inside a class and only use one entry point to make it easier to validate.
Let's say you are working for a car brand. In this case it might not be unreasonable to think that you are using the VIN number from the car as an identifier for the car. There might be several parts of our application interested in the VIN number, maybe for different reasons, for example: aftercare, dealers, insurance, ... The first thing that a part of our application will do is validate that the VIN number is valid. Why should we repeat ourselves in every part of the application and have the chance of forgetting to implement this check somewhere? We could create a VIN number value object with the validation built-in and pass it around in our application. Now let's say there comes an extension to how a VIN number looks like, this will cause you to have to search through the code for every occurrence and modify it. If it was already validated (and not forgotten to be implemented) and if we happen to find every occurrence (nothing says that it was implemented in the same way everywhere). By centralizing it you have less maintenance costs.
The previous sample was not really related to security (although it covered a bit of data security). It just showed that it could be handy to keep the validation as close as possible to the data. Time for another example: suppose you are working for a webshop now. Some parts might seem very trivial but might have a tricky outcome if they are implemented wrong. The flow for an order might be that an order with order items comes in. The order items might have an amount and an identifier for the product. Now let's zoom in on the amount. People should never be able to order a negative amount of order items. This would mean that we would owe the customer money and the customer would owe us a product. This was not foreseen in our business plan so we want to avoid it from ever happening. It might be a good idea to use an amount value object where you validate that the amount is a positive and natural number. This might seem weird to do for something trivial but the same amount that came into the system will be passed onto the stock management system, to the billing department and maybe to a customer care system, ... These systems could be part of our application. To be able to be consistent we would need to repeat ourselves on all these places and it is very easy to skip one place. Working with value objects makes it so much easier for everybody developing on the system because it is something less to actively think about.