First of all, specifications and tests are not always the same. Especially, the links you mention are really just unit tests, i.e. they are way below the level of typical specifications.

Here are some rebukes for your devil’s advocate:

• Reduces effort spent switching between files when editing specs:
  You gotta be kidding, right? We might as well use variable names a,b and c, because it reduces effort spent on typing. We have way more time-consuming tasks in software development than switching between files. This is not really an argument in our case, because even explaining it takes longer than what you save in a year when you apply it.

• Easy to organize and put specs next to tested implementation: You know, some IDEs allow you to open the corresponding unit test file from within your application’s source file. Additionally, unit tests are positioned next to the tested sources, only that next to means within the same module. Once you run integration tests, which are cross-cutting over modules, you cannot co-locate them with any one of the sources anyways. So again, this is not a real argument.

• Easy to encourage using unit specs in same file and integration specs in another file: That’s a strange reasoning here. You want to have unit tests in the same file, because it encourages you to have them in the same file? Circular reasoning isn’t very popular (esp. not with line managers if you get what I mean 😉 )

• Using specs and source together may increase sensitivity about lines written: This is in fact something we want to avoid. The whole point of test-driven development is to write the tests without even having any source code, and one reason to do so is because we want to test on a different level. We do not want to be fooled by the actual production code into writing tests tailored towards it. The tests should work for any code, and knowledge about that specific code may only load to a bad test.

In summary, a lot of people value the separation of test and production code. After all, the seperation means you do not ship test code. On the other hand, as your last argument shows, mixing the tests together with the code may cause more harm than good, and none of your arguments are convincing enough for me to even consider this idea.

Edit: Although you removed the arguments of the devil’s advocate, their counter-reasoning still gives reasons on why we don’t want to do that:

• You have little to no trouble finding a unit test for a class.
• Integration tests cannot be included with a source due to their nature (or at least it doesn’t make much sense to add them to one module, when they really test multiple modules).
• TDD means you should think about the design of your classes. Actual source code of that class is just a distraction to that and it makes sense to avoid this via the splitting.

Additionally, there are a few more arguments:

• Separation from production code: Test code by its very nature tries to break things and that makes it something that most people prefer not to give to a customer. In addition, if you do not include test code, you end up with a smaller bundle for delivery (not really significant though).

• Single Responsibility Principle: If you include the test code within the class, you break the SRP, because the class C is now responsible for X in addition to being responsible for testing that class C is doing X correctly.

• Version Control / History: Changes made to production code are important, and you want to be able to quickly see in the history of your version control system who did what. If you mangle this up with commits that only affected test code, you have a lot more noise.