I'm not sure that a library is really the right way to do this. In my experience, socket handling is a key part of the application, adding a library layer will make it harder to deal with the inevitable cases where the abstraction doesn't fit. An example of a simple, scalable TCP server (and a scalable client, so you can demonstrate the server), would be a better approach -- building a new server starting with the example would allow someone to make the changes they need when they need to. Avoiding unnecessary layers is a hallmark requirement of scalability, but this approach is adding one. One thing I can definitely see where the approach shown would be limiting is that often TCP servers would like to have a connection idle timeout, but if your peer is sending you a large application packet over a very slow connection, you wouldn't want to consider it idle because you hadn't received a complete application packet in some time -- having received partial packets should be enough to show that the connection continues to be alive (subject to concerns about slowloris).
Also, it's frankly hard to judge your claim of scalability, when you haven't provided any data. How many millions of connections can this handle (on which particular hardware), how many thousands of connections per second, how many gigabits of data transfer can you push, how many connections can you gracefully close per second, etc. What erlang settings did you have to tweak, what operating system limits did you have to tweak, etc to get there.
