Your design contradicts object oriented programming.
In object oriented programming (which is the core of the C# language) you combine data and logic in a class. This means a class is a construct that defines all of its properties (cost, level, children in your example) as well as what it can do. Hence you should of course combine those two parts,
Discussion of the matter in practice
1. Classes as pure data containers:
So much for the theory of OOP. In practice however this is not always practical to a full extent. Imagine a physics system, that has control over many objects exposed to it. Even though an object is theoretically capable of colliding with other objects it's better to leave those checks to a seperate system so it is easier to maintain, because it's centralized.
Second example: I'm doing a simple engine for a game at the moment and designed a rendering system. I created a Scene class, that holds information about all visuals (only geometry and lights). I have a second class Renderer, that operates on scenes (orders the lists for optimization and renders everything). Because the renderer can be configured in many ways all those functionalities are not included in Scene, even though they are directly tied to them. That way Scene is exclusively for holding data.
There are a lot of cases where classes are designed as pure data containers without any logic to them. However, if you have methods, that are immediately tied to your data container (Like your AddChildItemData method) there is no sense in outsourcing it. Imagine code like this:
ItemData data = new ItemData();
ItemData childData = new ItemData();
ItemDataManipulator manipulator = new ItemDataManipulator(data);
That's not readable and looks like an awful design.¹
2. Acess considerations:
However, there's another point to be considered: If you want some parts of the logic only be accessible to some part of your code (for example the part where you load data from disc) you might lean towards creating something like a creator class to hide this kind of logic from other parts of your software (you could for example decide not to make item modification available to mods). There are many other possibilities to achieve this (mainly access modifier) you should consider.
It depends. There are cases where classes (and - even more so - structs) are designed as pure data containers. But logic, that is only useful for this container, should be included in it. As I showed above, imagine you'd have to instantiate a seperate class to add a children to one of your objects. That's usually no smart design and over-complicates things.
But, as I discussed above: The design of your software completely depends on what you want to achieve and there is not definite answer.
Listing of various object-oriented design patterns (I did not read much of it, but it looks reliable)
¹: Note: There are software patterns where code like this is actually common. It can be useful to hide some features in certain situations. A little example: I'm using a builder pattern for keyframe-animations in my code with various operations that could be used when creating and editing operations. When applying the animation somewhere I don't need these operations. Patterns like this can be extremely useful when you want to expose only a certain set of operations in a given context.
Personally I follow this paradigm:
Try to keep your code as complex as needed, but as simple as possible.