I had to read this twice. And I'm wondering: Which part of Pi-hole is too slow? In my opinion, Pi-hole is already very fast. We've heard reports of deployments in schools and other networks with clients on the order of a few hundreds and they still run it on a Raspberry Pi 3. This is pretty amazing but I may be biased 
I will still go through your questions and answer them. Because we care about our users.
Some answers are already in my long reply above but I agree that they may be hard to filter out. There's no harm in repeating things if done in a different and maybe clearer way.
Millions of users are using routers provided by their ISPs (talking about Speedport, Vodafone Station, etc.) at home. A large portion of them does not offer a lot of settings, for instance, the Speedport W723 offers exactly two settings:
- Enable/Disable DHCP server
- Change the last two octets of the address range
192.168.XXX.YYY - 192.168.XXX.ZZZ.
You cannot change the DNS server handed out to the clients. They will all receive the router's address.
The solution to this was to embed a DHCP server into Pi-hole. Which is exactly why we have done this. Static lease configuration was added because a number of users wanted this (some routers allowed them to do this but still not offered changing the DNS server or do not accept internal IP addresses).
It is not performance-eating in any way. Agreed, it is using more disk space, but cheap SD cards and hard disks offer plenty of space. My gravity.db is 6 MB in size. All lists combined are 2.5 MB. This is not an order of magnitude in difference. I furthermore agree that building the database during pihole -g takes longer than simpler list copying into one file. However, this is also on the order of less than five seconds on a Raspberry Pi using a reasonable set of lists.
However, the database is much more powerful. You have structured information and can run any complicated query against the database you can imagine. In addition, lookups are much faster due to the database index. A grep through all the lists would have to walk each line. A lookup in the index can very well find a domain in less than 20 steps, even when gravity has 100,000 domains.
This is how the project started. I know this is not the best reason I could have pulled out of the hat, but I'm honest. Users have the freedom to chose whatever they want. A fill recursive resolver may not be the best fit for all.
DNSSEC is fragile and easily breaks things. I know that's not an optimal answer, either, but I would like to iterate once again that none of the developers is working in a full-time IT security job. However, we observe that DNSSEC is missing for google.com, facebook.com, yahoo.com, youtube.com, wikipedia.org, twitter.com, amazon.com and many more of the top queried domains within the Internet. One could argue that we could do it better than Google does, however, the lack of dev power suggests to focus on more important things that cannot easily break stuff.
We have an installer script that can install Pi-hole on a Raspberry Pi. It was tweaked over time to work on many many other flavors like Ubuntu, Debian, CentOS, Fedora, etc. All the various flavors make it hard to automate the installation of any additional software including their pre-configuration.
We do not recommend using free and public DNS servers, we just offer some of them to chose from during install. You can already specify your local (e.g.) unbound if you have it running before installing Pi-hole. Or you can install and use it after the installation. Your choice.
We offer official instructions here Redirecting... and even give support for this on our platforms. This is likely more than most would do. Especially for free.
Because Pi-hole is for users. We designed an adblocker for ourselves and decided to make it easily available for others, too. Without any fee, without any license costs. We are not looking to become another supplier of stuff for companies or earn money from it. A few users donate every now and then and this suffices to cover the costs for running the servers hosting this forum, the debug log container and some more infrastructure we use for internal communication.
We enjoy doing what we do. Most of the time. That alone is sufficient reward.