Can there be any unwanted effects by having several processes with the same sensitivity list in one architecture?
I have several processes that happen in parallel in an architecture, one process for reading input as a slave from a master which writes the input, one for writing output back to the master when the master asks for and one calculation. All the processes are clocked processes and their sensitivity list contains only the reset and clock signals.
Each process writes into its own signals, which the other processes may read from, i.e. there isn't an instance where two processes write into the same signal.
It's possible to implement everything in one single big process, but it'll be more cumbersome.
Can there be any adverse affects with such implementation?
Are there any reasons to favor the less elegant one big process over several smaller ones?
Not at all. Most of my processes have the same sensitivity list : (reset, clock) and this is not unusual.
If a single big process really is less elegant, and an implementation using multiple smaller processes is genuinely clearer and easier to understand, then go ahead and design that way.
I tend towards fewer, larger processes in my designs, but lay them out in discrete sections to make it easier to separate functionality within a process, but that's not a concrete rule : I wouldn't implement several independent state machines in a single process for example.
What I would advise against is two styles often seen :
If I understand your description you have something like 3 blocks : receiver, data processor, transmitter; and this sounds like a good separation of functions to me. For example you can more easily replace the receiver or transmitter, or re-use them with a different data processor, if they are separate processes (or even separate entities).