Here is my solution. A couple of words as a preface. There are two tasks:
#1

• Switches journal and fixes the name of new journal file (e.g., in @..#GtrlJ@("JrnFirst")).
• Processes the globals of a namespace. The algorithm of processing doesn't matter here, it's usually some kind of data re-coding. 

#2. This task occurred just because users' activity during the task #1 execution can introduce the changes in globals already processed by the task #1.

• Wait for the next journal file available for processing (WaitForJrnSwitch());
• Process the globals found in this journal using the algorithm similar to the task_#1's one.

The latter is a pseudo-code of WaitForJrnSwitch() method and GetJrnID(), its helper. 

/// If new jrn is available, set %JrnID=Jrn ID and return 1;
/// waiting by ..#TimeWait steps till ..#TimeLimit
ClassMethod WaitForJrnSwitch() As %Boolean
{
 set rc=0
 set nTimes = ..#TimeLimit \ ..#TimeWait
 for i=1:1:nTimes {
  $$$TOE(sc, ..GetJrnID(.JrnID)) // current journal
  if %JrnID="" {
    set JrnNext=@..#GtrlJ@("JrnFirst")
  } else {
    set JrnNext=%JrnID+1
  }
  if JrnNext<JrnID { // avoid extra journal switching ("by restore")
    set %JrnID=JrnNext
    set rc=1
    quit
  }  
  hang ..#TimeWait
 }
 quit rc
}


/// Get Jrn ID of the current journal file
/// Out:
/// returns %Status;
/// pJrnID - journal file name w/o prefix and "."
ClassMethod GetJrnID(Output pJrnID) As %Status
{
 set sc=1
 try {
   set file=##class(%File).GetFilename(##class(%SYS.Journal.System).GetCurrentFileName())
   set prefix=##class(%SYS.Journal.System).GetJournalFilePrefix() 
   set pJrnID=$tr($e(file,$l(prefix)+1,*),".")
 } catch ex {
   set sc=$$$ERROR($s(ex.%IsA("%Exception.SystemException"):5002,'ex.Code:5002,1:ex.Code),$lg(ex.Data)_" "_ex.Location_" "_ex.Name)
 }
 quit sc
}

Dear colleagues,

Thank you for paying so much attention to this tiny question. Maybe it was too tiny formulated: I should mention that objects instantiation impact is beyond the scope of the question as all of them are instantiated once; correspondent OREFs are stored in global scope variables for "public" use.

Going deep inside with %SYS.MONLBL is possible, while I'm too lazy to do it having no real performance problem. So, I've wrote several dummy methods, doubling instance and class ones, with different numbers of formal arguments, from 0 to 10. Here is the code I managed to write.

Class Scratch.test Extends %Library.RegisteredObject [ ProcedureBlock ]
ClassMethod dummyClassNull() As %String
{
  q 1
}

Method dummyInstNull() As %String
{
  q 1
}

ClassMethod dummyClass5(a1, a2, a3, a4, a5) As %String
{
  q 1
}

Method dummyInst5(a1, a2, a3, a4, a5) As %String
{
  q 1
}

ClassMethod dummyClass10(a1, a2, a3, a4, a5, a6, a7, a8, a9, a10) As %String
{
  q 1
}

Method dummyInst10(a1, a2, a3, a4, a5, a6, a7, a8, a9, a10) As %String
{
  q 1
}

}

My testing routine was:

ClassVsInst
   s p1="пропоывшыщзшвыщшв"
   s p2="гшщыгвыовлдыовдьыовдлоыдлв"
   s p3="widuiowudoiwudoiwudoiwud"
   s p4="прпроыпворыпворыпворыпв"
   s p5="uywyiusywisywzxbabzjhagjЭ"
   s p6="пропоывшыщзшвыщшв"
   s p7="гшщыгвыовлдыовдьыовдлоыдлв"
   s p8="widuiowudoiwudoiwudoiwud"
   s p9="прпроыпворыпворыпворыпв"
   s p10="uywyiusywisywzxbabzjhagjЭ"
   d run^zmawr("s sc=##class(Scratch.test).dummyClass10(p1,p2,p3,p4,p5,p6,p7,p8,p9,p10)",1000000,"dummyClass10 "_$p($zv,"(Build"))
   n st s st=##class(Scratch.test).%New() d run^zmawr("s sc=st.dummyInst10(p1,p2,p3,p4,p5,p6,p7,p8,p9,p10)",1000000,"dummyInst10 "_$p($zv,"(Build"))
   s st=""
   d run^zmawr("s sc=##class(Scratch.test).dummyClass5(p1,p2,p3,p4,p5)",1000000,"dummyClass5 "_$p($zv,"(Build"))
   n st s st=##class(Scratch.test).%New() d run^zmawr("s sc=st.dummyInst5(p1,p2,p3,p4,p5)",1000000,"dummyInst5 "_$p($zv,"(Build"))
   s st=""
   d run^zmawr("s sc=##class(Scratch.test).dummyClassNull()",1000000,"dummyClassNull "_$p($zv,"(Build"))
   n st s st=##class(Scratch.test).%New() d run^zmawr("s sc=st.dummyInstNull()",1000000,"dummyInstNull "_$p($zv,"(Build"))
   q

run(what, n, comment) ; execute line 'what' 'n' times
   n i s n=$g(n,1)
   s comment=$g(comment,"********** "_what_" "_n_" run(s) **********")
   w comment,!
   s zzh0=$zh
   f i=1:1:n x what
   s zzdt=$zh-zzh0 w "total time = "_zzdt_" avg time = "_(zzdt/n),!
   q

The results were:

USER>d ClassVsInst^zmawr
dummyClass10 Cache for Windows (x86-64) 2017.2.2
total time = .377751 avg time = .000000377751
dummyInst10 Cache for Windows (x86-64) 2017.2.2
total time = .338336 avg time = .000000338336
dummyClass5 Cache for Windows (x86-64) 2017.2.2
total time = .335734 avg time = .000000335734
dummyInst5 Cache for Windows (x86-64) 2017.2.2
total time = .280145 avg time = .000000280145
dummyClassNull Cache for Windows (x86-64) 2017.2.2
total time = .256858 avg time = .000000256858
dummyInstNull Cache for Windows (x86-64) 2017.2.2
total time = .225813 avg time = .000000225813

So, despite my expectations, oref.Method() call turned to be quicker than its ##class(myClass).myMethod() analogue. As there is only less than microsecond effect per call, I don't see any reason for refactoring.

The solution I've found is rather simple than smart: to start a dejournalizer as a JOB with an 'answer file' specified as a principal-input device. The code prototype looks like this:  

 set fin=$zu(12)_"Temp\fin.txt"
 set fout=$zu(12)_"Temp\fout.txt"
 open fin:("NW"):1 if '$t {write "not opened!",! quit}
 use fin write "N",!,"N",!,"Y",! close fin
 job jrnrest^ztestFF("20180614.006"):(::fin:fout):1 if '$t { w "not started!" q}

Its execution resulted in "fout.txt" file like this: 

20180614.006 to 20180614.006; c:\intersystems\cache\mgr\user\ => c:\intersystems\cache\mgr\test\

Do you want to rename your journal filter? o
Do you want to delete your journal filter? o


c:\intersystems\cache\mgr\journal\20180614.006
   8.88%  14.29%  15.26%  16.79%  18.08%  19.31%  20.35%  21.32%  ....
***Journal file finished at 16:39:36
Do you want to rename your journal filter? es
Journal filter ZJRNFILT renamed to XJRNFILT


[journal operation completed]

"o" and "es" were provided by the auto-completion of "N" and "Y" answers.

Cons of this approach is that ISC can change the ^JRNRESTO dialog in some future version.
Pros: no need in reverse engineering of ^JRNREST stuff to derive a non-interactive journal restore utility.

Hope my writing will be useful for somebody besides myself. Happy coding!