There are really two considerations: fulfilling the security requirements, and doing so efficiently.
Typically you would select the minimum secure block size depending on the type of algorithm in question, and the target operating environment. A block size that is too small can lead to attacks of time/space complexity that can be performed in practice. For an example, see the sweet32 attack.
Your question mentions hashes, but also mentions algorithm design in general, and the core of a hash function is often times a type of psueodrandom permutation (PRPs are arguably the workhorses of symmetric cryptography).
The block size will need to take into account the type of hashing construction, i.e. a Merkle–Damgård construction versus a sponge construction. For example, the full Keccak uses a larger state than many other designs, which may be related to the fact that much of the state is truncated before being output.
Using a block size smaller than 128 bits is almost guaranteed to enable attacks against your design (which may or may not be applicable, depending your use case). Larger block sizes tend to offer greater security.
Hardware considerations and performance play an integral role.
Using too small of a block size will not make effective use of the available registers on the machine. Using too large of a block size will also not make effective use of the available registers on the machine.
In an otherwise solidly designed psuedorandom permutation, memory accesses in the main loop can/will become the dominant cost, especially in the case of SIMD registers. If you have a bunch of MOV operations into an SIMD register in the main loop of your PRP, you will quickly eat into the advantage provided by SIMD.
SIMD operations are important. In order to compete on the throughput front, it is effectively a requirement to utilize SIMD operations. These instructions allow the application of an instruction to a larger number of registers in parallel. This will effectively multiply your block size while processing it in more or less the same amount of time.
Typically, you would initially target one of: constrained hardware, 8-bit platforms, 32-bit platforms, 64-bit platforms, then use the available SIMD instructions (if any) to increase the throughput of the design. Not all platforms offer SIMD operations - clearly, if you are designing for constrained hardware, this advice about SIMD does not really apply anymore.
Using a block size larger than 1024 bits is likely to be too big on almost any normal platform. To use a 1024-bit permutation effectively, you would need 64-bit registers, with 1 SIMD register spanning the length of 4 normal registers (256-bits), and 4 SIMD registers dedicated to your data (constants and other information that will also put pressure on the registers), then you can operate efficiently on 1024-bits at a time.
Modern desktop CPU's offer 64-bit registers. However, there are still many places where 32-bit platforms are used, as well as 8-bit platforms; Performance on these platforms will suffer if your design does not cater to them.
Similarly, if you design an algorithm that operates on 8 bits at a time, performance may suffer on a platform with wider registers.
Designing an algorithm that is friendly on all platforms is a topic of current research
In general, it will probably tend to yield a more balanced algorithm to design for an 8-bit or 32-bit platform, then run multiple instances in parallel via SIMD. This way you can ensure that performance is acceptable on all platforms, rather than excellent at one end of the spectrum, and horrible at the other.
Gimli opts for a 384-bit block size, so that is probably the sweet spot for balanced performance on all platforms. You may be able to squeeze slightly more performance out of a 512-bit block size, depending the nature of your design.
Why is the performance section larger than the security one?
If efficiency is not a concern, then the game becomes too easy. Just make everything huge. Don't expect your design to see use in the real world if you can't hash more then 20MB/s on a desktop CPU...