Here's a benchmark: in 1970, I had a full-time job maintaining a 4,000-line assembler program on punched cards. Today I manage a 400,000-line system in C++. That's 100:1.
That would postpone the point at which that assembly program reaches 400kloc. In the end, it would probably grow as fast as a C program of the same functionality.
Of course, they also would have to develop their own tooling around that DSL. That, I think is the problem lies with assembly. Higher level languages imply that more stuff gets shared between projects (even across companies; everybody will use the same C language and standard library), and that means time spent to develop tooling around and libraries on top of the shared stuff is useful for more people. Hence, tooling and libraries will generally be of higher quality. that home-grown GUI library built on top of a home-grown set of assembler macros using a home-grown ABI may be better than using, say, QT on top of X11, but it isn't that likely.
On the other hand, the smaller the system, the more important memory usage, and if the system is small enough, that can and will swing the advantage to the home-grown system. That happens less and less, though.
On your own? If yes, then that's pretty impressive. My previous team maintained 350,000-line Perl application with at least 5-6 programmers. If you're handling that C++ system alone, I'd assume it's pretty self-contained, since the complexity in large systems regularly comes from all the other systems that you interface with (at least for the aforementioned Perl app).