This is extremely important for many reasons:
Ease-of-use. This is allways the primordial motivation.
Automates some tasks that must be made before and after the installation of your Software. Again bringing ease-of-use.
Intelligently manages configuration files, documentation etc, providing more control in an upgrade
Manages interdependencies with other packages and versions, guaranteeing good functionality.
Lets you distribute Software with your company's digital signature, and makes integrity checks (MD5) in each file, guaranteeing precedence, and reporting unwanted file modification.
Provides tools to let interact with your graphic installer.
But a good package is not only put together your files in a RPM. FHS must be followed, configuration and documentation files must be marked as is, and pre- and post-install scripts must be robust, to not let them damage the system (remember that installation processes is done by root).
Know well RPM because it can bring much power and facilities to you and your user. There are a lot of documentation available about RPM on the Internet:
The book Maximum RPM, also available on-line and in printable PostScript format.
RPM-HOWTO which is smaller and more straight-forward.
You should give user the option to install only the part of your Software he wants. Imagine your Software has a client part and a server part, and both use files and libraries in common. You should break them in 3 RPMs. For instance, lets say the name of your product is MyDB, so you'll provide the packages:
MyDB-common-1.0-3.i386.rpm
MyDB-server-1.0-3.i386.rpm
MyDB-client-1.0-3.i386.rpm
and last 2 packages depends on the first. If the user is installing a client profile, he will use:
MyDB-common-1.0-3.i386.rpm
MyDB-client-1.0-3.i386.rpm
If he is installing a server profile:
MyDB-common-1.0-3.i386.rpm
MyDB-server-1.0-3.i386.rpm
This approach will help the user save disk space, and be aware of how your Software is organized.