You are using legacy OpenGL. It is fine for testing small simple things, but not good enough for "real" applications. And it is usually not feasible to start with legacy, and then upgrade, because it is done differently.

Have a look at Learning Modern 3D Graphics Programming, and you will quickly learn the modern way of doing it.

Unfortunately, most of the tutorials "out there" are done in the old way.

Specific differences between the 4 items you mentioned.

Immediate mode is fine for rapid prototyping and experimental work. It can be fine for learning, provided you recognise and accept that it's a suboptimal path that can lead you into bad habits, and that you plan to move away from it as quickly as possible. It's suboptimal for a number of reasons - more calls into the driver means significantly higher function call overhead, and modern drivers are likely to emulate it via a dynamic VBO behind the scenes - not a good idea if the data is not dynamic. It also involves transfer of a lot of data from system memory to the GPU, which again is not good for data that is not dynamic in nature. It's been deprecated from recent GL versions so you need to be aware that you're learning something of very limited future utility.

Display lists provide a mechanism for caching GL commands and data on the driver for subsequent future use. The driver may cache them in GPU memory or in system memory (you have no control over this) and there are a set of highly complex rules for what state gets cached and in what circumstances it happens. In the right cases and with the right hardware it can be the fastest method available, but not all drivers or hardware are equal. Once created you can't modify a display list - you can only execute it or destroy it. If state or data needs to change you're SoL. Display lists are also deprecated so clean interaction with current and future GL functionality may not be guaranteed in all cases - approach with extreme caution in other words.

Vertex arrays allow you to specify a vertex layout and data in system memory in a handful of calls, and transfer it to the GPU very quickly in a single call. This retains the immediate mode overhead of needing to transfer data that may not change every time, but removes the function call overhead. For older code or code that needs to be compatible with older drivers (and note that we're talking much older here - in the order of 10 years or so) this should be the preferred option. These are also deprecated, but - since VBOs are built on top of vertex arrays - are more likely to work well with modern OpenGL (e.g. instancing works perfectly fine with vertex arrays).

VBOs are the modern OpenGL way of doing everything. They're built on top of vertex arrays so they share the advantage of needing very few calls to specify and draw geometry, and have the added advantage that the data may be stored in memory that is more optimal for the driver. This suits static data perfectly, but does mean that you need to be slightly more careful about how you operate with VBOs if you're using dynamic data (although do note that using shaders as well means that much data which formerly needed to be dynamic does not necessarily need to be so any more). As a general rule VBOs should be fastest of all on the widest range of hardware, but do note that it's incredibly easy to write code using VBOs that runs slower than anything else if you're sloppy or careless.

With all that in mind my recommendation is to use vertex arrays for learning, but keep an eye on moving to VBOs. The reason why is that vertex arrays can share a lot of the same coding style as VBOs so you're primed for an easier move, but avoid traps for the unwary that can cause pipeline stalls throughout your program. Vertex arrays have also been available since OpenGL 1.1 so you can be very confident that driver support is ubiquitous. The same applies to VBOs, of course (although it's 1.5 rather than 1.1). So vertex arrays first and - when you get comfortable with them and build up more understanding of how things work in general - switch to VBOs.