.dtx is in some ways convenient as it means it is easy to send the entire package to others in one go. On the other hand, very few end users will actually use such a file: if I want to send someone a 'ready to go' package I either mail the TDS-style zip or link to it on CTAN.
For small packages a single
.dtx does make sense, and including the
.ins file in with the
.sty and README in the source can make life quite convenient as a package author. However, that assumes that the source file stays a 'reasonable' size to edit. For example, for
siunitx I currently have one source file but it's really too large and I'm planning to split it for a future release. On the other hand my
notes2bib package works as a single file as it's not too long.
One area to consider is user versus programmer documentation. If you plan to work on anything that provides a 'programmer interface' as well as a 'user' one then a separate
.tex source is useful. This applies for example to code using
expl3 where the LaTeX Team strongly suggest that all user interfaces come with 'matching' programmer ones.
As David says test files should almost certainly not be included in your source. Unlike the code, documentation and examples these do not need to be distributed to end users. For example, the LaTeX Team have a large test suite for LaTeX2e and tests for
expl3 but none of these go to CTAN as they are not needed outside of development work. (Aside: the team's building and testing system is available for general use.)
I'd say that if you are looking at multiple files including examples then you are probably better using one or more
.dtx for the code, code comments and programmer interfaces and separate
.tex file(s) for the user documentation and demos. On the other hand, a package made up of 10s of lines of code with a simple interface can be contained happily in one file.