The one over-arching issue I'd point to is that network pub-sub is the way to connect different parts of your system in ROS, and that's a bad default, and an ev

The one over-arching issue I'd point to is that network pub-sub is the way to connect different parts of your system in ROS, and that's a bad default, and an even worse single option. For most data-flow, you probably don't want to be hitting a serialisation step at all, but if you do, you probably want to be thinking carefully at the system level about how to move it around (how much data, what latency, from what kind of system to what other kind of system, how to deal with failures, corruption, etc), not just throwing it all into a general one-size-fits all approach. ROS systems tend to have multiple key control loops running through a transport that really likes to foul them up, and make for slow, unreliable behaviour. Most robotics projects that use it can get to it doing something pretty quickly, but getting it to work more than 20% of the time is a huge struggle. Otherwise, concrete problems are a bit harder to talk about, because they're very diffuse: while ROS has a lot of components and tools you would want in a robotics system, and they are all integrated together, the average quality is very low: they are on average slow, buggy, hard to use, and tend to lack important features, from build systems to GUIs. While it's tempting to use a it out of the principle that you shouldn't be duplicating work, in general I would say most robotic applications are far better served by using a custom framework that better fits their system design, using appropriate libraries for each part, but not an off-the-shelf do-everything framework (and it feels like there are gaps that could make this less effort, but in my experience writing your own replacements for ROS components is less effort than dealing with all the problems that come with using it: it's shockingly low effort to reach feature parity). (NB I haven't touched ROS for a while, but it doesn't seem like this has improved much, though there's been plenty of code churn)