In my opinion the most cohesive module is the one that doesn't exist or have just one small feature, and in the other hand the less coupled module is the one that only depends on itself
That's not really a useful way to look at things. Design is about managing change; if the software didn't change, you wouldn't be too interested in coupling and cohesion. It's not very useful to look at an isolated module from an outside, treating it as a single thing, a black box, and then say that it's highly cohesive and has no coupling. You care about interactions between things.
So, what you're interested in is how cohesive/coupled are different aspects within it (submodules, components, functions, logical groupings of code), with respect to certain types of changes. The word "cohesive" means "it sticks together". If you need to make a change, and you need to edit in three different places, then your code is not cohesive (a related thing is scattered in three places), and is coupled as a result of that (the three places are interdependent). It can be hard to bring these pieces together because of other accidental coupling - each of these pieces can be inadvertently coupled to something else. And the overall code will likely be coupled in other ways, too. So while you have a single module, if the module is not very small and if you didn't take steps to actively control the coupling, within it you'll have a tangled web of interconnections that will get in your way.
Making code more cohesive by restructuring it so that things that are interdependent but scattered come together eliminates some of the coupling between subelements, by confining it into a small, more focused cohesive component with an explicit boundary interface. You then work further to refine component interfaces to minimize inter-component coupling. The goal is to strategically control the coupling, and find a design (or arrive at a design) that'll mostly be conducive for the kinds of changes you can typically expect for your system. You have to study the domain over time to be able to do this.
(You can mentally replace app1, app2 with the more generic component1, component2. Note that going from (b) to (a) may require, among other things, moving parts from one box to the other.)
If you are successful in establishing such a structure, then that allows you to more easily choose a deployment strategy - you can deploy as a monolith, or you can divide it up into a number of libraries, or you can work toward making the system distributed over a network. It's easier to make a physical split if the coupling is minimized.
I see this issue in the Microservices world, where splitting things seems to be equal to "decoupling" your system. Then you have to touch 4 different services and 3 layers in each one to add a simple property
A split based on some arbitrary criterion does not equal decoupling. What you're describing here is exactly the low cohesion/high coupling scenario. It's not at all as simple as splitting things. People have noted before that a team has to be good at design, good at decoupling a monolith internally, before they can be effective at creating decoupled microservices. Because there's always a tradeoff; the distributed nature of microservices makes design problems much, much harder.