Because each step does different things

Prepare(setup) environment for building

./configure

This script has lots of options that you should change. Like --prefix or --with-dir=/foo. That means every system has a different configuration. Also ./configure checks for missing libraries that should be installed. Anything wrong here causes not to build your application. That's why distros have packages that are installed on different places, because every distro thinks it's better to install certain libraries and files to certain directories. It is said to run ./configure, but in fact you should change it always.

For example have a look at the Arch Linux packages site. Here you'll see that any package uses a different configure parameter (assume they are using autotools for the build system).

Building the system

make

This is actually make all by default. And every make has different actions to do. Some do building, some do tests after building, some do checkout from external SCM repositories. Usually you don't have to give any parameters, but again some packages execute them differently.

Install to the system

make install

This installs the package in the place specified with configure. If you want you can specify ./configure to point to your home directory. However, lots of configure options are pointing to /usr or /usr/local. That means then you have to use actually sudo make install because only root can copy files to /usr and /usr/local.

Now you see that each step is a pre-requirement for next step. Each step is a preparation to make things work in a problemless flow. Distros use this metaphor to build packages (like RPM, deb, etc.).

Here you'll see that each step is actually a different state. That's why package managers have different wrappers. Below is an example of a wrapper that lets you build the whole package in one step. But remember that each application has a different wrapper (actually these wrappers have a name like spec, PKGBUILD, etc.):

def setup:
... #use ./configure if autotools is used

def build:
... #use make if autotools is used

def install:
... #use make all if autotools is used

Here one can use autotools, that means ./configure, make and make install. But another one can use SCons, Python related setup or something different.

As you see splitting each state makes things much easier for maintaining and deployment, especially for package maintainers and distros.

Make is a general purpose workflow program, usually used for compilation. But it can be used for anything.

When you do something like "make all", the make program executes a rule named "all" from a file in current directory named "Makefile". This rule usually calls the compiler to compile some source code into binaries.

When you do "make install", the make program takes the binaries from the previous step and copies them into some appropriate locations so that they can be accessed. Unlike on Windows, installation just requires copying some libraries and executables and there is no registry requirement as such. In short, "make install" just copies compiled files into appropriate locations.

Generally speaking ...

1. "configure" (a) checks to make sure that your system meets whatever minimum requirements the program has; and (b) creates or customizes a compilation script (a "makefile") for your particular setup. It looks for things like what architecture you're running on, whether you have optional packages installed, whether your processor supports various extensions, etc. etc. Most large-scale programs can be compiled in various ways, and this is controlled by various flags passed to the compiler on your particular system. "Configure" figures out sensible defaults for these flags on your particular machine. (Often, they can be overridden by explicitly passing parameters to the "make" step if the "configure" script gets it wrong or you want to override its choices.)

2. "Make" performs the actual compilation of the program. That is, it turns human-readable programming documents into machine-executable code. Often, the default options can be overridden by passing options explicitly on the command line.

3. "Make install" puts the program binaries in sensible places where the system expects them to be. Often, this is the only place in the compilation cycle where you need administrative privileges (e.g., on Ubuntu and other Debian-based distributions, this is the only step you have to prefix with "sudo" to operate as the root user.)

EDIT: typo.

./configure runs a script named "configure" in the current directory. make runs the program "make" in your path, and make install runs it again with the argument "install".

Generally, the "configure" script was generated by a collection of programs known as "autotools". It checks your system and tries to generate a makefile (see below) appropriate for your system. It often succeeds.

This makefile it creates (usually called "Makefile", note the capital "M") is used by the program make (on Linux it's probably GNU's make, but there are other versions) to actually compile the software.

The make install command invokes make again, after the software is built, and tells it to execute the series of commands defined as "install" in the makefile.

These things are all conventional, so there's no guarantee that any random file named "configure" will actually do that, or that the target named "install" in a makefile will actually install software, but that's what most people expect from a file named "configure" in somebody's source directory: that it will generate a makefile to compile the program.

./configure

tells you whether are quite ready to build the application. It will check if you have everything needed to build the application, and, if it sees any critical errors it will inform you.

make

builds (compiles) the source code. Compiler compiles the code, but, most of the times, the code cannot stand alone, it requires external libraries (usually provided by ubuntu packages) to be installed. After this step the executable(s) of this specific application you are trying to install will be created.

sudo make install

moves all the needed for the application files to the appropriate system directories. This has to be done after make because the executables of the application have been created and can be moved to the appropriate system directory (e.g. /usr/bin/) for later use.

Libraries are necessary, because they allow a programmer to use code made by other people to achieve certain things. i.e. if I wanted to do some disk formatting in my program, I could use the libs someone already wrote to do the formatting, and I just have to make my program call those libraries. If that person finds an issue in their library, they can fix it, and it will fix it in my program too. This is how open-source software can be written so fast and be so stable.