In general the answer to your first question is Yes and I’ll come to an answer to your second question in a moment. Note first that this is a general answer to a general question and the bright sparks who hang around SO Fortran questions may well come up with special circumstances in which modules are inapplicable. I retort, in advance, that this answer is aimed at a newcomer to modules. Once you are no longer a newcomer you can formulate your own answer to your questions.
Modules are most useful to the programmer as an aid to organising and structuring a program or suite of programs. They provide a mechanism for encapsulating the definitions of user-defined types and functions/subroutines which operate on those types. In Fortran 90 and 95 this encapsulation was somewhat ad-hoc in the sense that it relied on the programmer’s ideas about how to decompose a program into parts. With the introduction of the object-oriented facilities in Fortran 2003 there are now even clearer ‘rules’ for identifying what elements belong in each module.
You could, for example, conceive of a module for types and procedures for rational arithmetic. By keeping all the code which implements your great ideas in one module you can hide the implementation from other parts of your program (which do not need to know the details) and expose only those parts you wish to expose (look at the PRIVATE and PUBLIC keywords). You can, right away, see another advantage to organising your code into modules; it’s much easier to USE your rational arithmetic module in a new program than it is to cut and past the code from your mega-source file into another mega-source file. When you want to work on your rational arithmetic, you work on code in one module, not in code spread all around your files.
Modules also allow you to manage name clashes. For example, your rational arithmetic module might define an operation called add, and you might also have a multiple-precision integer arithmetic module which defines an operation called add. If you attempt to USE both these modules in a program (or another module) then compiler will warn (possibly raise an error) that the same name is defined twice within the scope that uses the modules. You can use renaming when you use associate module entities. You can also use an ONLY clause to import only those module entities that the user needs.
Note that module USE is transitive, if A uses B and B uses C you don’t have to also declare that A uses C (though if you’ve renamed entities or specified ONLY clauses you’ll have to make sure what is transitive in a particular case).
In a nutshell, modules are the principal Fortran mechanism for dealing with complexity in programs by breaking them into manageable chunks. Fortran 2008, when the feature is implemented by compilers, introduces SUBMODULEs too, which promise even better support for dealing with complexity in this way.
Modules are also useful in that the language standards require that compilers generate explicit interfaces to procedures defined in modules for type-checking against the arguments at compile time. Note that these interfaces (which you never really see) are called explicit to contrast with implicit interfaces which is what procedures which are not defined inside modules (or CONTAINed within a program unit which uses them) have. You can, of course, write explicit interfaces for such procedures, but it’s almost always easier in the short and long runs to let the compiler do it for you.
As @Telgin has already noted, modules are an aid to incremental compilation too.