The "a bit faster" part is not very relevant, as it won't be noticeable
(maybe if you execute it 384.400.000 times).
The main reason - if the choice is mine - to choose the RPG implementation
instead of "default to" SQL, is that with a one-time investment you don't
have any dependency on SQL, and you can adapt the functionality of the
procedure to your own specific needs, if necessary. You're in control.
Especially if it's "simple" stuff, like replacing chars in a string, etc.
This example, calculating the weeknumber, is more tricky so i can imagine
you don't want to risk it. Also, there's not much reason to tweak or adapt
calculating weeknumbers. IMO, it makes things more simple, to not be
dependent on the SQL preprocessor and SQL runtime machinery just because
you have a couple of procedures which are a bit tricky to implement. For
me, it would be worth it. I don't dismiss SQL, of course, just use it for
what it was meant for.
It's a one time investment, and 90% of time is spent on gathering
information not actual coding, which will pay off the next x years. Once
implemented you can really forget about it. If it's implemented with
embedded SQL, and you forget about it, i think it will bite you sometimes
in the future. But maybe i'm wrong about this.
I also think that many programmers just don't want to implement it
themselves. E.g. a %replchar bif can be easily implemented with "normal"
rpg code, doesn't take days, and you can add all kinds of functionality you
think of instead of being "locked" into the functionality that's given by
the equivalent SQL bif.