Latency is due to the audio driver for the audio card. Cubase uses ASIO-drivers (an invention by Steinberg themselves) which mean they are optimized for the sound card if the manufacturer of the sound card makes ASIO-drivers available.
For sound cards that doesn't support ASIO there are workarounds such as DirectX ASIO (built-in in Cubase IIRC) and Asio4All driver wrapper.
In other words, it doesn't have so much to do with Cubase as to how the drivers work and are configured as well as the system's hardware.
Number one adjustment is always the buffer size. And here's why:
How buffers work
Audio data is processed using double or triple buffering. This is 2 or 3 buffers that are filled with data and then rotated so that while one buffer is played at the sound card, another buffer is filled with new data.
The buffers are rotated based on a timer, so no matter what, the buffers get rotated regardless of what currently is in the buffer. This is because the buffers are of a certain size which is related to data-rate and therefor synchronization - so this is important.
The software fills a buffer (f.ex after a MIDI note is received) and signal that it has finished and then receives a new buffer to fill. The process of rotating buffer is however expensive CPU-wise and to compensate for this one increase buffer size.
If the cost is still too high the CPU cannot process the data fast enough and fill a buffer before it gets rotated resulting in that the buffer contains no data or in some cases uncleared data which will cause noise and gaps in the audio.
This means that the buffer size must be increased more. And now the timer problem arises: the mentioned timer waits for the buffer based on its size. That means the bigger buffer, the longer wait.
If the delay becomes too long (>10ms) you will start to notice the delay when you play the keyboard compared to when the audio arrive at the speakers.
The obvious solution is therefor to tweak the buffer size so that the delay is lower as well as the CPU able to fill them before they get rotated internally.
At this point another factor comes into play, the harddisk if you are loading recordings/samples from disk - this applies also when you freeze tracks (I'm not covering this here, but in essence: the more fragmented it is the more time the disk controller use to look up file chains, seek sectors - with the exception of SSD disks - and load data into memory which add to the load on the CPU).
Always use a dedicated ASIO driver. These are optimized and work directly with the soundcard bypassing the system chain and therefor also reducing the CPU usage as well as delays.
Tweak the soundcard's buffers so that you find a balance between size and CPU capability. If you have a lot going on in the DAW the more the CPU is strained and therefor require a bigger buffer leading to increased delay. "Freezing" tracks that contains soft-synths and long effect-chains is always wise in these situation.
Optimize the harddisk by defragmenting it (seek permanent solutions such as Diskeeper). Can you reformat the disk with larger sector sizes then this is preferred (use f.ex. 16kb block sizes). This way more data is loaded per request and reduces overhead due to number of requests.
Is there enough memory in the computer so it doesn't swap to page file which again increase the bottleneck regarding the harddisk? Cubase is not necessarily having its data swapped, but other parts of the system may. Again, freezing tracks is a good way to get around this problem as well if putting in more memory isn't an option.
Do you work in 32-float? Try reducing to 24-bit or even 16-bit if needed. 16-bit consume only 50% of the data amount compared to 24-bit integer and 32-bits float, and is easier to process. At the final stage set 24-bit for render (Cubase uses 32-bit float internally when doing a final render). If you use samples this isn't always an option, but you can work with downsampled version of them and replace them at the final stage. It also affect some soft-synths as well as effects that adopt to the project's bit-resolution and therefor uses more CPU to process the sounds.