Dear @Dmitry Maslennikov !
Thanks for the compliment "bad idea"  !
All my life was driven by cross thinking, away from old tracks, doing the undoable, unchain my mind.
And it was 99% success. 

My ISC colleagues in and outside US can confirm this.
@Evgeny Shvarov knows much more details about me that would break the frame here.

BUT I'm a little bit disappointed. You didn't read the disclaiming note on top:
It is for developers, supporters,  system managers. 
And in addition my examples are never meant for production use,
but for training and learning. I don't make money with my software.

Just 1  minor detail:
Though multiple requests I never got a root password for any IRIS container.
You might have access to this information as you have also access to other no-public info.
So I had to set one for myself.  x-thinking!

All about the reasoning and other details are in my reply to @Evgeny Shvarov
Since he placed the more important question: WHY?

If you get back large results sets that you use for further processing PyODBC will be better suited.
But for a small number of values, the overhead at both ends to service ODBC structures may not pay off
since both ends have to get their internal structure in to  ODBC and out of it.
I don't have measured the difference so this is just a guess:
- for the typical embedded SQL returning < 1..10 rows a MethodCall might be more efficient.
This doesn't prevent you from using and tuning an SQL SELECT isolated in IRIS environment. 
In any case, the transfer between PY and IRIS is the slowest piece.
The less data you transport the faster the action is completed.
And transport in blocks wins over isolated pieces in loops.