I've been a ROS 1 (and now 2) user since 2010. I like the game engine analogy given elsewhere in the thread, in that ROS gives you some important things "for free" if you cooperate with its ecosystem conventions. Data bagging, visualization, teleop, and sim are the some obvious ones that I think a lot of teams don't think about if they're just focused on getting cartographer or whatever going, and not considering the larger development and debugging questions.

For some, packaging/deployment would also fall under the umbrella of a solved-by-ROS problem, however I don't think the Open Robotics supplied debs are suitable for most product deployments, for a variety of reasons that I've discussed in two separate ROSCon talks.

I usually feel the same when starting something new. The "STUFF" is annoying and often feels like overkill when a project is new and minimal. Installing/building ROS, the package boilerplate, etc. And often I can get away with more minimal alternatives like just a single (possibly multithreaded) process, or multiple processes with a simple IPC. But then again I often end up wanting a lot of the extra stuff you get with ROS like the bags, the viewers, the cli tools, etc. LLMs help on both fronts though - they're decent at making DIY versions of ROS-like functionality, but they're also pretty good at handling the ROS boilerplate. (Which is one area where I'd see peppyOS being a severe disadvantage).

As someone who has used ros2, I feel fine passing judgment; it is terrible. If its easier to write your own stack, do it. Your own stack will be easier to add to and maintain long term. The conceptual design (nodes) is great, its just the execution that is awful.