There is no performance benefit; it really is a matter of determining the prerequisites of your game logic. You want to run your logic with the assumption that the physics and actions are calculated WERE (didUpdate) or WILL BE (update). For example, an update is called before any physics and actions are processed. Therefore, if you have logic similar to user calculations in physics, creating a wall to block the physical body, or even just performing the action you want to run immediately, this should be done in the update method, because all these cases expect physics and actions will be calculated in the current frame. However, centering the node on the camera would be nice in didUpdate because you want to center your camera AFTER computing the physics.
It is also important to note that the update method conveys the current game time, so you will need to use the update method to calculate the time between frames (AKA division time). Often it is necessary to do such things as counting, to execute logic in N seconds or to process user physics with a variable time step. This will not limit you only to the update method, since you must save the current delta time in a variable so that you can access it from the didUpdate method and other callbacks.
From personal experience, I find myself using the update method more than didUpdate, simply because I often have a lot of customizable physics and logic that often assume that the changes made will be processed in the current frame. But, as I said above, it depends on your background. And in some cases it doesn’t matter what you choose, because the logic can be independent of the rendering cycle.
I think this image from the documentation for the sprite collection greatly facilitates the visualization of the growth cycle. Analyze your game logic and determine at what point in the cycle the game logic makes sense. 