Why would one omit the close tag?

While current PHP releases may have output buffering on, the actual production servers you will be deploying your code on are far more important than any development or testing machines. And they do not always tend to follow latest PHP trends immediately.

You may have headaches over inexplicable functionality loss . Say, you are implementing some kind payment gateway, and redirect user to a specific URL after successful confirmation by the payment processor. If some kind of PHP error, even a warning, or an excess line ending happens, the payment may remain unprocessed and the user may still seem unbilled. This is also one of the reasons why needless redirection is evil and if redirection is to be used, it must be used with caution.

You may get "Page loading canceled" type of errors in Internet Explorer, even in the most recent versions. This is because an AJAX response/json include contains something that it shouldn't contain, because of the excess line endings in some PHP files, just as I've encountered a few days ago.

If you have some file downloads in your app, they can break too, because of this. And you may not notice it, even after years, since the specific breaking habit of a download depends on the server, the browser, the type and content of the file (and possibly some other factors I don't want to bore you with).

Finally, many PHP frameworks including Symfony, Zend and Laravel (there is no mention of this in the coding guidelines but it follows the suit) and the PSR-2 standard (item 2.2) require omission of the closing tag. PHP manual itself (1,2), Wordpress, Drupal and many other PHP software I guess, advise to do so. If you simply make a habit of following the standard (and setup PHP-CS-Fixer for your code) you can forget the issue. Otherwise you will always need to keep the issue in your mind.

People are always able to make mistakes, no matter how smart they are. Adhering to a practice that reduces the number of possible mistakes is (IMHO) a good idea.

PHP is not XML. PHP doesn't need to adhere to XMLs strict standards to be well written and functional. If a missing closing tag annoys you, you're allowed to use a closing tag, it's not a set-in-stone rule one way or the other.

Eschewing ?> however solves just a trickle of the common headers already sent causes (raw output, BOM, notices, etc.) and their follow-up problems.

PHP actually contains some magic to eat up single linebreaks after the ?> closing token. Albeit that has historic issues, and leaves newcomers still susceptible to flaky editors and unawarely shuffling in other whitespace after ?> .

Stylistically some developers prefer to view <?php and ?> as SGML tags / XML processing instructions, implying the balance consistency of a trailing close token. (Which btw, is useful for dependency-conjoining class includes to supplant inefficient file-by-file autoloading.)

Somewhat uncommonly the opening <?php is characterized as PHPs shebang (and fully feasible per binfmt_misc), thereby validating the redundancy of a corresponding close tag.

There's an obvious advise discrepancy between classic PHP syntax guides mandating ?>n and the more recent ones (PSR-2) agreeing on omission.
(For the record: Zend Framework postulating one over the other does not imply its inherent superiority. It's a misconception that experts were drawn to / target audience of unwieldy APIs).

SCMs and modern IDEs provide builtin solutions mostly alleviating close tag caretaking.

The regular ?> close tag is also known as T_CLOSE_TAG , or thus "close token".

It comprises a few more incarnations, because of PHPs magic newline eating :

?> n (Unix linefeed)

?> r (Carriage return, classic MACs)

?> r n (CR/LF, on DOS/Win)

PHP doesn't support the Unicode combo linebreak NEL (U+0085) however.

Early PHP versions had IIRC compile-ins limiting platform-agnosticism somewhat (FI even just used > as close marker), which is the likely historic origin of the close-tag-avoidance.

Often overlooked, but until PHP7 removes them, the regular <?php opening token can be validly paired with the rarely used </script> as odd closing token .

The " hard close tag " isn't even one -- just made that term up for analogy. Conceptionally and usage-wise __halt_compiler should however be recognized as close token.

__HALT_COMPILER();
?>

Which basically has the tokenizer discard any code or plain HTML sections thereafter. In particular PHAR stubs make use of that, or its redundant combination with ?> as depicted.

Likewise does a void return; infrequently substitute in include scripts, rendering any ?> with trailing whitespace noneffective.

Then there are all kinds of soft / faux close tag variations; lesser known and seldomly used, but usually per commented-out tokens:

Simple spacing // ? > // ? > to evade detection by PHPs tokenizer.

Or fancy Unicode substitutes // ﹖﹥ (U+FE56 SMALL QUESTION MARK, U+FE65 SMALL ANGLE BRACKET) which a regexp can grasp.