Custom iterator performance is very poor compared to allocating an array and traversing it

[Xrayez]

Godot version:
Godot 3.2, 4.0+.
Previous issue discussion: #7218.

OS/device including version:
Windows 10, likely any OS.

Issue description:
I'm (re)implementing/porting a linked list implementation as seen in Godot core/list.h which I'm going to expose to scripting via C++ modules: goostengine/goost#12 (with some fixes upstreamed in #42013).

As you may know, as described in the documentation, Godot provides a way to override for loop iterators via script for any custom object both via script and C++ (you just have to ClassDB::bind_method for them to work in script via C++). This feature is also used in PackedDataContainer (#38701), so this could also improve the engine itself on some level, not just modules.

The crux of the issue can be described with the following snippets:

extends Node

func _ready():
	var list := LinkedList.new()
	for i in 100000:
		list.push_back("Godot")
	# Allocate array.
	for node in list.get_elements():
		pass
	# Custom iterator.
	# This performs 10 times worse on average compared to above.
	for node in list:
		pass

From the user perspective, I'd rather use the custom iterator solution because that's essentially what built-in collections/containers are able to do. At it's current state, it's better to allocate an array with get_elements rather than using custom iterators, because they only provide convenience. There are even initial GDScript implementations out there: willnationsdev/godot-next@72c0f7f, but the entire idea of implementing a list data structure in C++ is exactly performance.

There was some solutions for this in the past: #7225, but the implementation was deemed too hacky to implement in core, so perhaps we could find a solution which is not hacky.

Also, feel free to transfer this issue to GIP, because I realize that performance is not a priority for Godot development, as described in the documentation:

Also, Godot's philosophy is to favor ease of use and maintenance over absolute performance. Performance optimizations will be considered [emphasis mine], but they may not be accepted if they make something too difficult to use or if they add too much complexity to the codebase.

Steps to reproduce:
Checkout #42052 where this is implemented for iterating Nodes children similarly (for which I can create a proposal as well, if desired).

Minimal reproduction project:
custom_iterators.zip