Ask Questions and Find Answers

The answer to the question really depends upon what you think you are getting...

If you see Liferay (the thing) as a platform, not a product, you will likely see these options as too limiting. As a platform for building custom solutions, it may be necessary to explicitly override, extend or remove pieces to implement the vision.

Liferay (the company), however, is not selling or giving a way a platform, they are selling and giving away a product. And just like any other product, there's a "void warrantee if opened" concept, but this message has not always been broadcast or received correctly every time.

Therein lies the rub - if you treat Liferay (the thing) as a platform, you are inherently taking on the responsibilities of the voided warrantee concept.  It's why Liferay support will not help with any custom code, especially customizations. Support will often try to reproduce issues in a Vanilla Liferay instance to try to determine if a reported problem is a Product issue or a Customization issue; Product issues they can help with, but Customization issues they can't.

That's why their recommendations exist. They provide approved ways for you to extend and customize the product without violating the "void warrantee if opened" clause, to stay within the boundaries for supportability.

And just like any product that has the same kind of clause such as your cell phone, they document approved ways to customize and use the product, but they certainly aren't going to tell you how to open the cover and make changes to the internals and violate the "warrantee" in the process. These kinds of options may be covered in personal or external documentation (probably some of my blogs fall into this area), but they will not make it into the product documentation.

Thanks for your time for this detailed explanation.  You have a valid point from Liferay Platform. I have a valid point from customer platform.  Though Liferay upgrades many things in further versions, customer doesn't need them until they require that functionality / new upgrade features. 

If you add security updates to that list, that'll make it more obvious that you want to optimize for ease of maintenance, not for ease of getting things done once and forever without looking into the future much.
One option, if you really modify JSPs is to introduce custom "dynamic includes" (because Liferay itself only has very few of them built in). They're easy to locate in your edited JSP, thus should be relatively easy to port forward. Then implement the dynamic include in a proper plugin. This is easier to maintain than adding dozens of lines to a JSP file and doing 3-way-merges on every update.