My personal experience speaking from a company with little resources to spend nor expertise on DDS configuration:
We started our work in ROS2 galactic using Fast DDS. At the time we had very frustrating issues about services not responding, not being discovered or answering with a huge latency + some high CPU usage (all of that was reported). And it was NOT a distributed system: everything was running on a powerful x86 computer under Ubuntu 20.04 (cannot be more standard). Nothing too fancy: customized nav2 stack, 3D pointcloud processing pipeline using composition to avoid serialization, and hardware interfaces.
All our problems magically disappeared when switching to Cyclone DDS.
In retrospect, the highest cost of switching from ROS1 to ROS2 for us was to tackle DDS related issues (another example: localhost only that needs multicast enabled on the loopback interface to work and how to activate it, i.e. “ip link set lo multicast on”, that information was hard to find).
From what I read in this post, it seems that there are still some instabilities on the core ros functionalities (publish/subscribe/topic/service/action) linked with the default DDS vendor change. In that sense (node-to-node communication on a single computer), ROS2 is still not iso with ROS1. In ROS1 it just works.
My feedback as a “naive” ros user: I believe there are some quality system tests missing targeting DDS functionalities. It is not normal that the issues we experienced under Galactic about the services went unnoticed. Same for current issues affecting subscription with callback group under Humble. If it is a matter of DDS configuration, then the default configuration should work out of the box at least on a standard system (x86 Ubuntu LTS) for standard ROS interface (publish/subscribe/topic/service/action). I don’t think it is acceptable to wait for an non rolling release to test and iterate on these issues. I can totally understand the need to dig into the configuration for exotic use cases, but let’s remember that the vast majority of users runs ROS on a single computer without having to worry about network latency, QoS and packet loss between nodes.
I am willing to help to describe basic test use cases if needed.