My experiences involve CruiseControl.NET and Team Foundation Build. I'm a .NET developer myself. These come from my experiences, and only include the experiences where we had testing as part of the build process, so if they don't match your environment, sorry.
I'm also wondering if it's necessary to have a specific engine to run the tests, or is it enough to have them integrated into our continuous integration engine
If you are doing a build every check-in, it is possible to have builds triggered before the previous build is finished running. How do you want to handle situations like this? For example, if it takes 30 minutes to run through the entire test suite, and code gets checked in every 15 minutes, do you want to skip a few builds? Skip some tests? Stack them up, build them in order and get back to Bob that he broke the build with his check-in 5 hours ago?
Team Foundation Build can use multiple cores for builds and tests with 2010 (previous versions could only use multiple cores for C++ builds). CruiseControl.NET can run separate threads, but reading the documentation, it appears that each project can be on its own thread, but that you can't have multiple threads per project (I may be wrong). We've never had a multi-core machine for builds in the environments I've worked in, so I can't speak to how good/fair/bad they are (or wrong I am).
At one previous employer, we included Python scripts in the build, but we didn't have any testing set up to test the Python. NANT was used for the .NET components.
I'm also wondering if it's necessary to have a specific engine to run the tests
I never had time to do it, but at a previous employer (we sold "shrinkwrap" software), we had many bugs that were operating system specific (and sometimes service pack specific), so one of my goals was to set up multiple test machines with different OSes (both 32 + 64 bits and all the various flavors of desktop and server Windows from XP onwards). The build machines were simple and older WinXP machines (or virtuals) because that was all the "hardware" we were allowed by the managers. Instead, all tests ran on the build machine. We also set up validation suites as collections of unit tests, although these were not run for minor updates.