Question: Is use of VO´s (POCO) a bad design pattern? Some people say that all domain logic of an object needs to be together in that object.

Ex.: ProductVO: Id, Name, Description

ProductBO: SearchById(int id), Insert(ProductVO newProduct), Update(ProductVO updatedProduct, SearchByKeyword(string word)......

Answer: 
Using VO's lets you decouple state from behavior, which sounds incompatible with OOP, but may well be appropriate when different aspects of the application view the state with their own goals in mind.

A general argument against VO's is that they allow invalid states, but what constitutes validity may well differ depending on what stage something is in a processing pipeline or what treatment it is being considered for. For example, data entry may require only that the birth year is in the past and not over 120 years ago, but qualification for a student will impose a tighter range. The VO could be created from importing or data entry, then passed to a student business logic object that maintains a reference to the VO and ensures validity with regard to its requirements. The student can then be passed around, instead of the raw VO, allowing full object-oriented behavior. This works particularly well if the business logic object exposes the VO through an immutable interface.
Not a bad design pattern if used properly.
For me POCOs should have only intra-object logic, all inter-object logic belongs in the business layer.