Here by asymptotic analysis I assume we mean
the behavior of algorithm as the size of the input goes to infinity.
The reason we use asymptotic analysis is because
it is useful in predicting the behavior of algorithms in practice.
The predictions allow us to make decisions,
e.g. when we have different algorithms for a problem
which one should we use?
(Being useful doesn't mean it is always correct.)
The same question can be asked about any simplified model of real world.
Why we use simplified mathematical models of the real world?
Think about physics.
The classical Newtonian physics is not as good as
relativistic physics in predicting the real world.
But it is a good enough model for building
cars, skyscrapers, submarines, airplanes, bridges, etc.
There are cases where it is not good enough,
e.g. if we want to build a satellite or send a space probe to Pluto or
predict the movement of massive celestial objects like stars and planets or
very high speed objects like electrons.
It is important to know what are the limits of a model.
It is typically a good enough approximation of the real world.
In practice we see often that
an algorithm with better asymptotic analysis works better in practice.
It is seldom the case that an algorithm has better asymptotic behavior
So if the inputs can be large enough then we can typically
rely on asymptotic analysis as a first prediction of algorithms behavior.
It is not so if we know the inputs are going to be small.
Depending on the performance we want
we may need to do a more careful analysis,
e.g. if we have information about the distribution of the inputs
the algorithm will be given we can do a more careful analysis
to achieve the goals we have
(e.g. fast on 99% of inputs).
The point is as a first step asymptotic analysis is a good starting point.
In practice we should also make performance tests but
keep in mind that also has its own issues.
It is relatively simple to compute in practice.
Typically we can compute at least good bounds on the asymptotic complexity
of an algorithm.
For simplicity let's assume that
we have an algorithm $A$ that outperforms any other algorithm on every input.
How can we know $A$ is better than others?
We can do asymptotic analysis and see that $A$ has better asymptotic complexity.
What none of them are better than the other in all inputs?
Then it becomes more tricky and depends on
what we care about.
Do we care about large inputs or small inputs?
If we care about large inputs then it is not common that
an algorithm has better asymptotic complexity but
behaves worst on large inputs that we care.
If we care more about small inputs then asymptotic analysis
might not be that useful.
We should compare the running time of the algorithms on inputs we care.
In practice, for complicated tasks with complicated requirements
asymptotic analysis might not be as useful.
For simple basic problems that algorithm textbooks cover
it is quite useful.
In short asymptotic complexity is a relatively easy to compute
approximation of actual complexity of algorithms for simple basic tasks
(problems in a algorithms textbook).
As we build more complicated programs
the performance requirements change and become more complicated
and asymptotic analysis may not be as useful.
It is good to compare the asymptotic analysis to
other approaches for predicting the performance of algorithms and
One common approach is performance tests against random or benchmark inputs.
It is common when computing the asymptotic complexity
is difficult or unfeasible,
e.g. when we are using heuristics as in say SAT solving.
Another case is when the requirements are more complicated,
e.g. when a program's performance depends on outside factors and
our goal might be to have something that finishes
under some fixed time limits
(e.g. think about updating interface shown to a user)
on 99% of the inputs.
But keep in mind that performance analysis also has it's issues.
It does not provide mathematical grantees on the performance
on less we actually run the performance test on all inputs that will be given
to the algorithm (often computationally infeasbile)
(and it is often not possible to decide some inputs will never be given).
If we test on against a random sample or a benchmark
we are implicitly assuming some regularity
about the performance of the algorithms,
i.e. the algorithm will perform similarly on other inputs that
were not part of the performance test.
The second issue with performance tests is that
they depend on the test environment.
I.e. the performance of a program is not determined by the inputs alone
but outside factors
(e.g. machine type,
efficiency of coded algorithm,
utilization of the CPU,
memory access times, etc.)
some of which might vary between different runs of the test on the same machine.
Again here we are assuming that the particular environments
that performance test are carried out are similar to
the actual environment unless
we do the performance tests on all environments that
we may run the program on
(and how can we predict
what machines someone might run a sorting algorithm on in 10 years?).
Compare these to computing
the asymptotic running time of say MergeSort ($\Theta(n \lg n)$) and comparing it with the running time of say SelectionSort ($\Theta(n^2)$)
or BinarySerch ($\Theta(\lg n)$) with LinearSearch ($O(n)$).