There are some smaller issues in your code, which I mention later. But the main issue I see is that it's quite useless, since it doesn't make your code any shorter.

If you compare:

try
{
    /* some code */
}
catch (SomeException ex)
{
    /* more code */
}

with

FunctionalHelpers.TryCatch<SomeException>(
    () => /* some code */,
    ex => /* more code */);

then the latter might look shorter, but that's mostly an illusion. It's more complicated, it's actually longer (if you count the characters) and you could also write the original code like this:

try { /* some code */ }
catch (SomeException ex)
{ /* more code */ }

Though I'm not saying you should do that, this code looks terrible.

The point of the article you linked to was to be able to handle several different exceptions with the same code without repeating. Your methods can't do that.

Now to the minor points:

public static void TryCatch<TE>(Action tryAction, Action<Exception> handler)

You should use Action<TE> instead. This way, you can easily access properties that are specific to that type of exception.

public static void TryCatch<TArg, TE>(Action<TArg> tryAction, TArg args, Action<Exception> handler)

I don't see much point in having overloads with args. It's usually much easier to use closures (though slightly less performant).

public static void TryCatchFinallyUsing<TE, TUsing>(Action<TUsing> tryAction, Action<Exception> CatchAction, Action<TUsing> FinallyAction, TUsing arg)

It seems you missed another point the article made. If you have TUsing as a simple parameter and the code that creates that object throws, it won't be caught by your CatchAction. You should have Func<TUsing> instead.

Also, you should use consistently name parameters in camelCase, not PascalCase.

public static void TryCatch<T1>(Action tryAction, Action<Exception> handler, Action FinallyAction)

This method should be called TryCatchFinally.

There are some smaller issues in your code, which I will mention later. But the main issue I see is that it's quite useless, since it doesn't make your code any shorter.

If you compare:

try
{
    /* some code */
}
catch (SomeException ex)
{
    /* more code */
}

with

FunctionalHelpers.TryCatch<SomeException>(
    () => /* some code */,
    ex => /* more code */);

then the latter might look shorter, but that's mostly an illusion. It's more complicated, it's actually longer (if you count the characters) and you could also write the original code like this:

try { /* some code */ }
catch (SomeException ex)
{ /* more code */ }

Though I'm not saying you should do that, this code looks terrible.

The point of the article you linked to was to be able to handle several different exceptions with the same code without repeating. Your methods can't do that.

Now to the minor points:

public static void TryCatch<TE>(Action tryAction, Action<Exception> handler)

You should use Action<TE> instead. This way, you can easily access properties that are specific to that type of exception.

public static void TryCatch<TArg, TE>(Action<TArg> tryAction, TArg args, Action<Exception> handler)

I don't see much point in having overloads with args. It's usually much easier to use closures (though slightly less performant).

public static void TryCatchFinallyUsing<TE, TUsing>(Action<TUsing> tryAction, Action<Exception> CatchAction, Action<TUsing> FinallyAction, TUsing arg)

It seems you missed another point the article made. If you have TUsing as a simple parameter and the code that creates that object throws, it won't be caught by your CatchAction. You should have Func<TUsing> instead.

Also, you should consistently name parameters using camelCase, not PascalCase.

public static void TryCatch<T1>(Action tryAction, Action<Exception> handler, Action FinallyAction)

This method should be called TryCatchFinally.