Sure, and by mentioning CDuce and the paper, I hope they can now be used as additional examples to expand your experience. There are also many smaller trade-offs each of those implementations make that directly impact performance (inference vs non-inference, local vs global analysis, etc).
Which cases? Can you please elaborate? Because the paper is about set-theoretic types and implementation of set-theoretic types, so I would be surprised if the suggestions listed there do not apply to the set-theoretic type system we are implementing.
Correct, but it is yet not decided that integers will be singleton values in our type system. Dialyzer chose singletons because it aligns with their trade-offs but it is unclear if this choice would be beneficial to us (for both performance and false positive reasons). We may choose between integer(), pos_integer() or zero() or neg_integer(), or each integer as a type.
My point is: sure, the type system can still be slow at the end, but extrapolating from X, Y, and Z, to draw conclusions is still just a guess. So let’s be aware of pitfalls, do the work, and then make decisions.
Again, there is no point in trying to optimizing something if we are not sure it is going to fully suit the language. I understand if you’d prefer that, but it is not my preference.
In any case, you are more than welcome to try a different direction! I’m looking forward to insights you might have and challenges that may arise when implementing the existing algorithms and optimizations on the Erlang VM. 
