Is there better way to shorten this Lambda expression's result selector?
Naming
Your entities / POCO classes have badly named members (assuming the entity names themselves aren't really named the way you've posted them), that break the C# naming conventions for public members - they should be PascalCase, ...and what's with the Hungarian notation? Also disemvoweling is never a great idea - call a table Table instead of Tbl, and we'll know you didn't mean Team-Based-Learning... whatever.
public class Table2
{
       [Key] 
       public int Id { get; set; }
       public long AccountNumber{ get; set; }
}

Entities are NOT database tables; they MAP to database tables, and they're classes - so they should follow the naming conventions for C# classes. If they're mapped to tables/columns on SQL Server with different names, you should use the appropriate [Column(&quot;columnName&quot;)] attributes (or fluent API configurations) to specify the mapping.
Convention over Configuration
Entity Framework is able to infer a lot of things from the way you name things. Having a property called Id in an entity type, is automagically inferred to be that type's [Key] - hence, the explicit attribute is redundant / noise, and should be removed.
Tbl1 is breaking this convention. The [Key] field bintAccountNo should be called Id, and the table should be called Account - so when other related entities have a property named AccountId, Entity Framework knows that's a FK property.
Navigation Properties
One of the greatest things about EF is its ability to simplify the querying of complex relationships between entities, using navigation properties.
public class Account
{
    public long Id{ get; set; }
}

public class Table2
{
    public int Id { get; set; }
    public long AccountId { get; set; }

    public virtual Account Account { get; set; }
}

You mention in a comment that you find the generated T-SQL inefficient when you're using navigation properties; how exactly is it &quot;inefficient&quot;? It's verbose, yes, but that doesn't make it inefficient. Have you performance-profiled it? What's the bottleneck? Could you be missing indexes?

Your Query
I like that you're using the method syntax, but it's not clear what's being queries exactly, because the code you posted looks like it's querying the type itself:
var b = (Tbl1.GroupJoin(...));

One would expect something like this:
using (var context = new MyDbContext())
{
    var result = context.Tbl1s.GroupJoin(...));
}

GroupJoin
This is where the query syntax gets handy, see what exactly is a group join? on Stack Overflow:
Join syntax:
from p in Parent
join c in Child on p.Id equals c.Id
select new { p.Value, c.ChildValue }

GroupJoin syntax:
from p in Parent
join c in Child on p.Id equals c.Id into g
select new { Parent = p, Children = g }

And that calls GroupJoin() for you under the hood, and it's easier to mentally picture what your data looks like, I find.
I'm not quite clear on GroupJoin followed by SelectMany - why not just do a regular Join then?