Так что это за «грозная» точка на конце доменного имени?

На самом деле с этой точкой всё просто.
Согласно RFC 1034 (см. $3.1 стр.7)

 ...Since a complete domain name ends with the root label, this leads to a printed form which ends in a dot.  We use this property to distinguish between:     - a character string which represents a complete domain name      (often called "absolute").  For example, "poneria.ISI.EDU."     - a character string that represents the starting labels of a      domain name which is incomplete, and should be completed by      local software using knowledge of the local domain (often      called "relative").  For example, "poneria" used in the      ISI.EDU domain.</blockquote> 

То есть точка в конце доменного имени указывает, что это полное доменное имя (FQDN). Если точки нет — значит имя относительное. Кому приходилось конфигурировать DNS сервера — видел эту точку в файлах зон.

Так почему же в адресных строках браузеров мы всюду наблюдаем доменные имена без точки на конце?
Формат Uniform Resource Locators (URL) документирован в 1994г. в RFC 1738 (см. $3.1 стр.5 )

  host         The fully qualified domain name of a network host, or its IP         address as a set of four decimal digit groups separated by         ".". Fully qualified domain names take the form as described         in Section 3.5 of RFC 1034 [13] and Section 2.1 of RFC 1123         [5]: a sequence of domain labels separated by ".", each domain         label starting and ending with an alphanumerical character and         possibly also containing "-" characters. The rightmost domain         label will never start with a digit, though, which         syntactically distinguishes all domain names from the IP         addresses. 

То есть host — всегда либо FQDN либо ip — другого стандарт не предусматривает.

Как видите тут идёт ссылка на секцию 3.5 RFC 1034, но в секции 3.5 описывается предпочтительный синтаксис DNS имён

 3.5. Preferred name syntax  The DNS specifications attempt to be as general as possible in the rules for constructing domain names.  The idea is that the name of any existing object can be expressed as a domain name with minimal changes. However, when assigning a domain name for an object, the prudent user will select a name which satisfies both the rules of the domain system and any existing rules for the object, whether these rules are published or implied by existing programs.  For example, when naming a mail domain, the user should satisfy both the rules of this memo and those in RFC-822.  When creating a new host name, the old rules for HOSTS.TXT should be followed.  This avoids problems when old software is converted to use domain names.  The following syntax will result in fewer problems with many applications that use domain names (e.g., mail, TELNET).  <domain> ::= <subdomain> | " "  <subdomain> ::= <label> | <subdomain> "." <label>  <label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]  <ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>  <let-dig-hyp> ::= <let-dig> | "-"  <let-dig> ::= <letter> | <digit>  <letter> ::= any one of the 52 alphabetic characters A through Z in upper case and a through z in lower case  <digit> ::= any one of the ten digits 0 through 9  Note that while upper and lower case letters are allowed in domain names, no significance is attached to the case.  That is, two names with the same spelling but different case are to be treated as if identical.  The labels must follow the rules for ARPANET host names.  They must start with a letter, end with a letter or digit, and have as interior characters only letters, digits, and hyphen.  There are also some restrictions on the length.  Labels must be 63 characters or less.  For example, the following strings identify hosts in the Internet:  A.ISI.EDU  XX.LCS.MIT.EDU  SRI-NIC.ARPA 

и нет ни строчки про финальную точку в fqdn

Вот тут, видимо, точка и потерялась…