I worked on a robotics project with a large team using ROS1. The loose coupling is pernicious: It's easy for everyone to work on their own ROS node in isolation and avoid testing the integrated system. There's no compiler to help you find all the clients of a node, etc.
Loose coupling is good if you mainly use open-source packages and modify one component for your research paper. I'm not sure it's a net positive when building most components yourself.
A big multithreaded program can still use queues instead of locks to share data between threads.
So many of these comments sound like engineering process flaws.
Everyone's working on their own ROS nodes in isolation....with no thought to eventual integration testing? It doesn't seem like that is a fundamental shortcoming specific to ROS.
- a large amount of data can be transferred asynchronously. Pub/Sub is a great pattern to achieve that; the cases when you need a synchronous interface are the minority.
- a robotic software has MANY components, you need an approach that incentivize decoupling and lousily-coupled interfaces.
- this lousily-coupled architecture has been a catalyst for innovation and cooperation, because it makes it easier for people to share their code as "building blocks" of a larger system.
Is there a considerable overhead? Sure! But it is much more complicated to write thread-safe code in a huge, monolithic application.