S3D doesn't make identical gcode to the other slicers. They are all unique in their own way. But as far as I can tell, I don't see anything wrong with the S3D gcode that doesn't follow the gcode specifications. You could ask the same question, why does S3D gcode work on every other firmware out there just fine except for smoothie?
I've already read about several bugs in the smoothie firmware that they were working on fixing. Several of them created bugs with how it processes standard gcode, for example, there was an issue awhile ago with how smoothie handled G92 E0 commands. I think that may be resolved now, but that's a perfect example of a firmware bug that wouldn't affect all slicers, because not every slicer uses G92 E0 commands. So there could easily be other issues like that, which is why only one particular type of gcode is triggering the problem.
Either way, the fact that S3D's gcode works with every other firmware out there seems to make this a pretty easy argument.
And why do you say that S3D doesn't want to work with the smoothie team? I remember emailing with their team awhile ago and they had actually already purchased smoothieboards on their own to help make sure the software was compatible.