Microsoft SQL Server accept blank in name of variables - Why?

Question

Microsoft SQL Server accept blank space in name of variables by usage of brackets:

CREATE TABLE [dbo].[MyDataTable](
    [Compo 1] [nvarchar](50) NULL,
    [Compo 2] [nvarchar](50) NULL,
    [Compo 3] [nvarchar](50) NULL,
    compo1 [nvarchar](50) NULL,
    compo2 [nvarchar](50) NULL,
    compo3 [nvarchar](50) NULL,
    compo_1 [nvarchar](50) NULL,
    compo_2 [nvarchar](50) NULL,
    compo_3 [nvarchar](50) NULL)

Problem is what happens when a tool like entity framework or NHibernate or any other ORM tool or even manually I try to create a model based on my database?

When using C#, VB.NET, Java and probably most development language it is never possible to use white space in your variable name.

So, to fix this LINQPad default provider ignore and remove white space when generating C#, Linq2Db alternate provider seems to replace blanks by underscore. All these generation rules can conflict with other variable in my database in case I have a variable that already is the alternative solution like in my example.

In LINQPad I have this

MyDataTable.Compo1; // With capital letter and mapto [Compo 1] [nvarchar](50) NULL,
MyDataTable.compo2; // with small letter and map to compo2 [nvarchar](50) NULL,
MyDataTable.compo3;
MyDataTable.compo_1;
MyDataTable.compo_2;
MyDataTable.compo_3;

So, my questions: how is it possible that Microsoft accepted this as SQL valid column name? Is it part of SQL standard or specific to SQL Server? What can be a correct positive use cas of using blank in my column names?

Possie

A beginning of answer here : link "I understand the need for creating columns with spaces in them, especially for reports that users will interact with, it's not very user-friendly to have a column heading labeled as 'Client_Response_Status_Code'." But I'd like to find a clear answer from ms like you. – Geophyte

You can do much weirder things in table names, as long as the object is in square brackets. You can use spaces, line feeds or any other non-printable character. It'll even accept a char(0). I think it more a feature by accident than specifically designed. – Middelburg

Off-topic. No one but the original designers of tsql (likely from Sybase) can answer this question. And it doesn't really matter, does it? This is a problem you created. The rules for regular identifiers are documented and well-known. – Upstart

To be honest I expect no correct answer or people asking to close the subject because considered as primarily opinion-based, off topic, unclear, or similar. I'm expecting to be able to say "there is no reason they did so and this is better to never user space and special character in these column name" – Possie