Supporting modded blocks has been requested a few times already, but I propose a different solution for that issue.

Instead of manually adding blocks from other mods, generate them automatically from a config file. No fancy mechanics (like doors or levers), if block id is in the config you assume it's a solid block and just add the reinforced variant and a recipe for/from it. If the reinforced block doesn't really work because of some custom mechanics of the original block, that's on the modpack maker, not on you.
(Support for blocks like stairs or slabs would be nice and still pretty easy, but that's a secondary concern).

Considering how many reinforced blocks already exist in the mod, I'm guessing you have some semi-automatic way of generating them, so parsing additional config file through it shouldn't be that much work. And if the automatic tinting of the textures is too hard to implement, just use the original ones.

Even something as simple as this would really go a long way and allow for more seamless integration of SecuriCraft into a modpack.

No. First of all, adding registry entries via config files is discouraged, especially because server & client configs need to match (i.e. have all the same blocks, items, etc. loaded). Then there is the problem of the model and blockstate info which has to be somehow generated at runtime and injected into Minecraft's systems for that. The info has to match the original block, be prepared for the use of reinforced block tints, and have otherwise no differences with the original block, which can not be easily done while keeping compatibility with all kinds of possible block models. We do make use of vanilla's data generators for the default reinforced blocks, however they are ran prior to compiling the mod, and simply generate files that are put into the mod's assets directoy. It's nothing that can be used for creating models/blockstates/etc. on the fly. Everything else regarding adding a new reinforced block is manual work.
I'd like to object to it not being our responsibility when a custom reinforced block does not work like its vanilla equivalent. The reinforced blocks we add by default are all supposed to work like their non-reinforced counterpart, and breaking that assumption for other reinforced blocks (even when created by modpack makers) is a no-go.
Multiple problems arise when creating such a system. For example: What happens when the block has multiple textures? We can't just assume every block has one texture for all sides. What happens when a block's placement is direction-dependant (think pillars)? What's with blocks having special handling for [insert thing here]*? Such a config system becomes very complicated very quickly. There's no way we'll support something like this, especially since it is very easy to create 3rd party mods that add reinforced blocks for the blocks of other mods. This solution is favorable in any case, and it's even possible to keep the original block functionality this way.

* e.g. custom block (collision) shapes