I think the main reason for disallowing integer array arithmetic in MATLAB is because of the ambiguity caused by the max(min( )) behavior of integer arithmetic. Unlike other languages such as C/C++ that typically do modulo arithmetic for overflow situations, MATLAB does extreme value clipping. E.g., take this operation:
uint8(200) + uint8(200)
In C/C++ this will result in mod(200+200,256) = mod(400,256) = 144
In C/C++ you can string together several such operations and get a consistent answer regardless of the order of operations.
But in MATLAB this results in max(200+200,255) = max(400,255) = 255
This results in MATLAB depending on the order of operations. E.g., take this expression:
uint8(200) + uint8(200) - uint8(200)
Group the operations in two different ways:
(uint8(200) + uint8(200)) - uint8(200) = 255 - 200 = 55
uint8(200) + (uint8(200) - uint8(200)) = 200 + 0 = 200
So, depending on the order of operations you get two different answers. This becomes problematic when the operation involves anything other than real scalars because of the operation order ambiguity noted above. Depending on assumptions made for operation order of intermediate expressions when using arrays, you can get a completely different answer. To avoid this ambiguity, MATLAB simply disallows it.
My guess is that you want to treat this operation as a floating point operation, in which case converting the operands to floating point prior to the operation as Jan suggest is the way to go. You can always convert the result back to an integer type after the operation.