The ethernet cable has an external jacket and you shouldn't be modifying that jacket, so you won't be doing any shield connecting unless you add shielded female-to-female couplers and have two patch cables per segment - a bad idea. So I'm not even sure how "connecting the cable shield option" even came up? How did you plan to actually implement it, in physical terms? In industrial applications you should be using premade well shielded CAT6 (or better) cables, rated for flex use in your case, and you should not be modifying them unless you have the engineering resources to fully characterize such modifications (it's not a trivial matter even if you're an experienced manufacturer of such cable assemblies).
Once that's out of the way, it's clear to me that what everyone intends is for the endpoints to provide some high frequency coupling between the shield and the local earth or case of the device, but it shouldn't do much at the typical operating frequencies of motor drives/inverters, and certainly not at DC - because the impedance of those connections between PE and the shields are the only real ways to direct the unintended currents away from the data/signal cables, and if they are "zero" then you have effectively no control (ferrites won't help much with servo inverter frequencies). Some designs where this wasn't well understood will connect the ethernet jack shields directly to the metal case, and that's often a problem and may even disqualify products from certain applications (I, for one, wouldn't want to deal with it) - even if it may make passing EMC testing easier.
You can use a plain old multimeter to measure resistance between the metal case/PE terminal of the various elements of your system and the shield of the ethernet jack. As long as no more than one endpoint of each connection has a low impedance "short" between the cable shield and the frame, you'll be fine. As an example: to the best of my knowledge, on all modern Beckhoff components that have a plastic case around the EtherCAT jacks, there is no low impedance DC path between Ethernet jack shields and PE/frame/enclosure (e.g. drives in metal enclosures have a plastic panel where the signal connectors are).
If you're serious about reliability, the motion controller should keep an angle totalizer on all rotary joints, and a displacement totalizer on all sliding joints, and the HMI/OPC interface should provide maintenance alerts once your estimated flex life of any of the cables is "coming up" and eventually when it gets used up, as it ultimately will unless your manipulator will have very low duty cycles (that may well be in some applications - you have to engineer that). You'll need such totalization anyway to estimate bearing life of the joints, to diagnose apparently premature wear/failure of components, etc. In my experience, few people do that, and it always turns out to be a serious shortcoming when something fails/wears out and there are easy questions with no answers (e.g. "how much rotation did this gearbox survive?"). And make sure the values of those totalizers are not lost across PLC upgrades - typically you'd want them in a dedicated record/structure type, and declared persistent (do invest in the "second UPS" for the PLC/controller so it can persist those when power is removed - you don't want to be scribbling on flash storage continuously, and you won't win any friends if the service/plant maintenance people will have to pry the data from some OPC overlords who collect the data in their ivory siloes; think of the common man!). In robotic applications I prefer to keep an angle/displacement totalizer, as well as (angle or displacement)^n*(bearing load)^m product totalizer (at least for n=m=1, but depending on your wear models you may wish to store a couple different exponent combinations - it's way less data than logging everything, and sometimes when things go seriously wrong the large-scale log storage may be unavailable for examination, so totalized data stored in a dedicated EtherCAT-based nonvolatile memory module can be a lifesaver).
You also need to bypass as much current as you reasonably can around bearings. Some joint assemblies for use in robotics have built-in grounding wipers with a specified life, qualified for use as PE connections, so you won't need your own grounding then. But that would be explicitly specified for those components. Otherwise you'll need to design the flexible bonding straps between the manipulator segments to have sufficiently low impedance - especially in light of the common-sense requirement of testing the impedance of such connections even if they may otherwise fly under the radar. And you'll need to ensure that the production does not let a DC grounding continuity test that failed "high impedance" around a moving joint pass unnoticed: sometimes even a single such test can pre-wear the bearings enough that their life goes down by a factor of 10 or worse. Connecting a 100A ground bond tester across a rotary or sliding rolling element bearing joint with the bonding straps missing can be the equivalent of pouring some sand into the bearings. Or not. But I imagine that you'll be dealing with expensive mechanical components, so it's best to avoid even the potentiality of such inadvertent damage. And of course ground bond testing must be done with all other cables but the ground strap unplugged - just because the motors may be "grounded" via their power cable shields doesn't make it acceptable nor sufficient, and you really don't want to push ground bond test currents through those).
Ah, of course the ground bonding flex straps will have a different life than the Ethernet cables, and potentially also than other cables, so you have to keep separate totalizers for each class of cable, so that they can be replaced for preventive maintenance, and your field monitoring should have a process to inspect those grounding straps, and amend their life estimates based on field experience, and field maintenance by factory reps should definitely include a cable test on all industrial ethernet segments using a cable certifier - at least until you develop some field experience and have enough accumulated motion to make statistical predictions to guide your cable maintenance/replacement intervals. I don't know your exact application, of course, so these may not be a big concern, but there must be some engineering done to support that, and it costs infinitely less to replace the cables before they fail.
I shouldn't be mentioning that you should be running totalizers for EtherCAT physical layer errors for all nodes as well. My limited field experience indicates that even if your system is well integrated into the factory environment and the diagnostic data is streamed to higher level systems, getting timely and flexible access to it may be an insurmountable problem. So, from a manufacturer or integrator's viewpoint, whatever diagnostic data you hand off to others for "safekeeping" is best presumed absent when truly needed. This stuff may seem far removed from frame grounding, but the weakest link is always the critical one - and when you face field failures, having reliable diagnostic data that you have unquestioned access to is a difference between trusting your system vs. witch hunts.
