I've often asked myself, and others this question, and I'd like to address a point I often see brought up before I get to why Linux sees fewer installers:
Linux distributions provide package managers.
However, I wouldn't say that a Linux distribution's package manager is a replacement for an installer for, in part, the following reasons:
These package managers aren't standardized in operation
A package manager is a bit like providing your binary and letting the end-user choose the installer. They can choose the terminal, or they can choose a tool with a more advanced GUI, but it doesn't afford you the same level control of the process as with a "traditional" installation wizard.
An example of what I mean by control is documentation. You can't give your end-user instructions like "Click Next, and you should see ". You can give command-line instructions for a specific tool, but then you're not only relying on the fact the user has that tool, but also losing most of the benefits of an install wizard (after all, most wizards are providing a front-end for simple command line instructions and kicking off scripts).
This also ties into aesthetics. Now you're depending on your end-users distribution to provide an intuitive/appropriate interface. While you are fully aware of that fact, it's not unreasonable for a more casual user to complain if double clicking your file (installer in their view) opens up an ugly package manager, does nothing at all, or worst of all opens up a terminal window. (The experiences I've had with users and their aversion of the "dos prompt" / "black and white box" / "Thing that's going to delete all their files if they look at it funny" could probably fill a book)
Package formats aren't standardized across platforms.
There are tools to convert between systems like rpm and deb, but it's not reasonable to expect your end-user to convert your packages if you're using them in a situation where an installation wizard would be provided on another platform (i.e. clicks-and-done).
Providing up-to-date packages for an additional package format can be rather straight forward if you have a rudimentary build system, but you're still adding a new binary that needs to be supported.
That's also adding a new binary people have to choose from depending on their platform (it sounds minor, but I'm sure someone here can attest to having to explain x86 vs x64 before [yes, there are ways to deduce the right platform from the browser, but then you're getting into even more complicated, and harder to support, procedures])
Package managers are "nicer" to open-source software.
This isn't saying that you can't share closed-source software with a package management system, it can definitely be done. But once you try to share close-source software on Linux distributions you run into a wall as far as your options for getting your software into common repositories is concerned. Things like PPAs or the openSUSE Build Service are out, and even the Canonical Partners repositories aren't enabled by default.
That means, unless you provide your own repository, you can't many of the major features of package management systems, including automatic updates. In my opinion, this is the most important benefit across most platforms that use these systems (e.g. iOS, Android, and Windows Store).
And even if you provide a repository (another job of variable triviality), you still need to get users to set it up (which is another layer of support, another set of non-standard approaches, and another diversion from the original point of the installer)
Now, having said all that, I still haven't addressed the original problem, why installers are less common on Linux in spite of these factors (amongst others). The original question asks if it's technical, or based on convention, and it's based on both in part.
If you look at the above factors I've mentioned, they also make things more complex for a "wizard-like" installer. For example, would your wizard include multiple package formats to install? How do you handle look-and-feel across distributions? The list goes on, and one thing that that packages do afford you is that none of this will be your concern (for better or for worse) as long you provide the right packages. And depending on the nature of your project, you can start to take advantage of those more "specialized" resources, like submissions of apps to the Ubuntu Software Center. This would all relate to the technical.
But the aspect that I personally find to be the driving force is convention. (I hope I've buried this deep enough that the people who downvoted that other answer to oblivion have stopped reading..)
I feel that poster had a point, but might have stated it too bluntly, and not actually provided objective reasons for that point. If you examine the differences I stated for a package manager and an installer, I wouldn't be surprised if you found most of them to be nearly non-issues (maybe even bordering on pedantic). But (excuse what I hope is viewed as legitimate use of an ad hominem argument) we're also users on site for programmers. I see Linux distributions pushed as an excellent Windows alternative for casual users (amongst many other things obviously). Not providing a commonly defined clicks-and-done procedure that all of these users can use really isn't ideal imo.
But at the same time, I don't find that many things in Linux to be especially ideal for that group either. Sure some distros have GUI-based package managers, but that means these people have to start looking into how to use a separate tool, on that isn't strictly focused on your program's installation (compare this and this to this).
Naturally you can use the GUI to do a majority your average casual user needs to do, especially with certain distros (ironically the things those distros are doing aren't always embraced in the open source community [look at complaints about Ubuntu and it's "walled garden"]) But I don't think it's deniable that Linux conventions favor someone who's comfortable with a CLI, or at the very least not deathly afraid it's appearance means they did something horribly wrong.
I'm not saying that this is what they aim for, but it's really what I see those conventions do. And package management systems in Linux seem to be following that. After all, most of their "downsides" nearly non-existent if your end-user is more comfortable with the underlying concepts.
Installers on most other platforms aren't really affected by that, and are designed so, to quote a comment on the question, "99.99% of users [can] blindly click "Continue". The problem with package management is getting those users to a "Continue" button, letting them know what that "Continue" button is (I've seen users get tripped up by tools that said press enter with other text), and letting them know when they've hit that "coast on clicking the "Continue" button" stage.
