The first statement is true, but it is meaningless on Linux or on any systems. It is because most drivers or hardware handling is done by interrupts and it is impossible do it differently. For example, if a packet arrives from the network, the CPU will know it by an interrupt initiated by the network card.
But these interrupts are invisible for the user space processes, and it doesn't affect them.
Except rare, typically embedded scenarios, no Linux work without interrupt handling.
What can cause race condition, is the context switching, i.e. if the kernel gets away the CPU from a process and gives it to another one. It happens typically by an interrupt from the timer. If only a single process runs, or if the whole scheduler is somehow turned off (maybe it is possible in some embedded environment, but very atypical), then this doesn't happen, and you have a single-process system a'la DOS. It is true, that there is no possibility of a race condition because there is no multitasking.
In a multi-CPU system, if multiple CPUs are concurrently active, there is also the possibility for a race condition, because multiple threads can run concurrently even if there is no scheduler active. Note, also this scenario is very alien to Linux (or to any not embedded OS).
The second sentence, "threads are not interrupting each other" is mainly true. Threads are essentially processes, using the same address space. Multiple threads typically don't interrupt each other. Maybe they could send signals to each other, but that is all. This statement is independent from the previous one.