Besides, I'm not a Linux user and my point of view is definitely biased 
So, the question is : what would be the benefits of using autotools (except that it will scare Windows users and make me unable to maintain the Linux build) ? Do the Debian packages use anything else than the provided makefiles ?
Currently, the debian packaging is there, but it's not very usable to developers because it has no way to inform them where SFML is located.
So, let me give you a brief on what i believe should be the correct way to distribute SFML for unix systems.
Originally, the only "correct" way to distribute a package was using autotools. As you know, libraries and includes in unix systems can be installed anywhere, like /usr/include /usr/local/include , /opt/pkg/include/ or even the bizarrre locations in OSX. This proved to be a mess when distributing a library because whoever was going to use it had to know where your favorite unix installed it.
Because of this, autotools introduced a system where your library provided "Scripts" written in a strange mixture of M4/sh that, when running autoconf would include them into the configure phase. This way, scripts would detect where the library is.
This system was in place for more than a decade or two. it "worked" but sice autotools is a mess, a lot of projects either had no choice or didn't use it and wrote their own library detection code (checking common install paths or forcing the user to tell where libraries were installed). Until a few years ago, this was the only choice.
Fortunately, and now backed by the freedesktop people, an extremely handy tool called pkg-config was developed. pkg-config is very simple script where you can query information about your app, given it's unique unix name.
http://pkg-config.freedesktop.org/wiki/So, transforming sfml to use pkg-config shoudl be easy and straightforward.
You can keep using makefiles if you like, just the way you are now, or move to something more advanced such as scons, but the procedure is the same.
1) Check for the existence of pkg-config. pkg-config should be available in the path normally when invoked, if not, fail.
2) Check for the existence of every dependence using pkg-config. All sfml dependencies are already in pkg-config database, so just run similar to:
pkg-config openal --exists
pkg-config openal --atleast-version=0.0.5
(or a version you know it's compatible)
and check the program exit status value for 0 , if not 0 then it means openal is either not installed, or not the version needed by sfml, so fail compilation.
then, you must request pkg-config the compiler and linker flags to use the library with
pkg-config openal --cflags
pkg-config openal --libs
and add them to our CXXFLAGS / LIBS in the makefile.
So, finally, when you are done compiling and you are asked to "make install", you must generate and install (besides includes and libs) an "sfml.pc" file in $(PREFIX)/lib/pkgconfig that will inform applications compiling against SFML where the library is located and how to compile against it. It's simple!
Right now the debian install doesn't include pkg-config info, so it's pretty useless even if debianized.
Also, another feature of pkg-config is that it helps you when you want to upgrade your library and break api compatibility. Imagine you want to make SFML 2.0 . just make pkg-config provide a "sfml2" package, and include /usr/include/SFML2 and link against libsfml-audio2.so for example.
About build system, if you want to use something more complex than makefiles (but not nearly as messy as autotools) , that will also run under windows/mac using native compilers i'd recommend you to take look at:
scons (a python framework, the most advanced build system and used by most complex projects today)
cmake (a metabuild system that generates makefiles)
omake (a build system a bit similar to scons based on make syntax)
Well, hope any of this is of use.
Cheers!
