You should be aware that lots of modules are "standard" and come with Perl. These are called "core" modules. See core.

They seem cumbersome and slow.
That's not true for all of them. I frequently use the core module: List::Util. In the distribution of Perl that I use, this comes compiled as an XS version, meaning that the code is implemented in C and runs like a rocket. The functions are all "short", but somebody took the trouble to implement them in a more efficient way than just native Perl.

As you gain more programming experience and start writing larger applications, you will want to build modules of your own! The current project that I'm working on today has about 12 modules that I developed.

Some of these modules are used in a number of my projects. One example: I've got some special functions for dealing with one particular time format that I use a lot. I wrote some of this stuff years ago, but I keep recycling this code easily by using my module. I test and maintain this code separately from the applications which use it. It is very reusable for the type of projects that I do - maybe in the future I'll make it more general purpose so that it can apply to more types of projects. Many CPAN modules evolve this way.

Some modules are only used by one application and are modules because they represent a clearly defined "thought unit". One such example I have is about 800 lines of Perl and what it does is darn complicated, but my interface to it is only about 5 things even though it might run for 5 hours. It has its own version numbering, revision history and tests. So even though only one application uses this module, I created it to help me manage the complexity of the overall project.

Anyway, at some point you will find yourself doing a lot of copy and pasting code from previous projects into current projects and the idea that this is a hassle will occur to you. Maybe once you see why you'd write your own module, you will more fully understand why you might want to use a module written by somebody else?