Say I'm developing a C++ command line tool of moderate scope. I have a couple dozen classes, and a main() driver function that lets the user do a few things with the tool.

I could have one .hpp and one .cpp for each class or major unit of functionality, and a Makefile that builds each .cpp into a .o and then links all the .o files into an executable. Then I can have my interfaces in header files, with all the doc comments, and my implementations in separate files.

Or, I could not bother with any of that boilerplate, put all the definitions for a functional unit in the header, mark them all inline, and throw away the .cpp.

In modern compilers, inline doesn't actually have a lot to do with whether the compiler decides to inline any particular function call, and now mostly seems to exist to let you turn off the one definition rule. If I put all my function definitions for a unit into the header file, I can keep them together and not be constantly paging back and forth between the description of what the code is meant to do and the actual code. It won't matter if the header gets included in multiple translation units, since inline makes it legal to link the results together.

And if I do this for the whole project, I no longer need any translation units other than the main.cpp one anyway, or a separate link step. I don't have incremental recompilation, but in a small to medium-sized project that might not be a big downside, and I have the upside of a single-compiler-call build process. My code can be re-used in a project that does use multiple translation units just fine, because of all the inlines.

I feel like this is a Bad Idea, but other than "that's not traditional" or the loss of incremental compilation for large projects, I'm not sure what to say to convince people not to do this.