There are practical reasons to do that. That is common in realtime systems. Trying to isolate the cpu for a particular process. So that is available faster when that process needs it. You could also have n-realtime processes. You don't want them competing for the same CPU if you know ahead of time you can allocate a CPU for each one of them.
Another reason is caching. For example you can assign a CPU to process network interrupt requests from a particular network device. Then you might or might not want to also assign the process that consumes that data to that CPU.
CPU affinity certainly has a useful purpose; however, I said "needlessly". As in, what if every process on your system selected a CPU when it started, and just waited for that CPU, to the point of leaving other CPUs idle or underutilized? And what happens when you get stuck behind a process which requires a huge pile of CPU resources? The problem becomes even worse with batch processing: every process must run to completion before the next one for that CPU can run.
In a typical real-time system you don't have to deal with random processes screwing things up. Resources are meticulously allocated to individual tasks, and the tasks aren't allowed to randomly grab resources in the scenario you describe. It all has to be planned out in advance.
There are practical reasons to do that. That is common in realtime systems. Trying to isolate the cpu for a particular process. So that is available faster when that process needs it. You could also have n-realtime processes. You don't want them competing for the same CPU if you know ahead of time you can allocate a CPU for each one of them.
Another reason is caching. For example you can assign a CPU to process network interrupt requests from a particular network device. Then you might or might not want to also assign the process that consumes that data to that CPU.