We was discussing the implementation of inline crypting this way (using create_function) 3 months ago (re: https://github.com/phpseclib/phpseclib/pull/65 ) and it was for the benefits of ~25% speed up accepted.
But not only ~25% speed up was the advantage, also we could highly optimized the Rijndael algo with his different blocksize, which results in same performance as AES with fixed blocksize. Wich results, as a second advantage, in code-reducing in AES.php (where we was then able to remove the whole block-mode and the whole AES optimized fixed-blocksize algo code in AES.php)

So there are huge Advantages (code-reducing in AES and a generic Performance+ in all ciphers of ~25%) ... not only disadvantages like bad coding style, unable for bytecode caching (which, in this case, can be ignored anyway), complexer maintaining (which will fixed with Crypt_Base) 

In my opinion... the Advantages we get from using create_function for highly optimzed fast cipher[mode] code outweighs over the disadvantages of using it.

But... it's possible to use the clousre anonymous function instated of create_function/eval... introduced since php 5.3... which means: Real code, bytcode cacheable, [php]modern programming style.
In fact, the first implemention of inline crypt was using clousres, of course which was only activated detecting php >= 5.3.

But there was, it seems, a unclear "Bug" in PHP with the clousres (...possbile memory leak) which i was discussing in dev.php und a core PHP developer confirmed that and add a bugreport related to this here: https://bugs.php.net/bug.php?id=64291
So we (respectively Terra) then decided to use create_function (which was also great for full php4 compatibility... so since then all php versions geht the Advantages form inline crypting) waiting for the bug fix in PHP...

So thats the current history of the inlinecrypting using create_function().

If it now not wanted anymore, after all the previews intensive discussion arround it, i then respect this and are still able to remove it from all ciphers.


But personally i say, because phpseclib has on it own special demands (beeing ultra compatible, no PHP module requirements, and be fast as possible... see AES which is the fasted pure PHP-AES-cipher implementation on the Net... and with inline crypting even more... which make, in my opintion, phpseclib unbeatable und that way uniqe for AES)

... so personally i say: Special demands, special code :-)

(ahh i just see Terra's comment about it...)