Awesome question!
Personally I ALWAYS think about my client's experience. You know the old saying, "A happy wife is a happy life!" That's very true with clients as well. Here are my thoughts on your list of 5 approaches.
1. This is an OK solution but the second to last option I'd use (if at all). Reason being is you have to write custom code. You have to worry about the code being "upgradable" with new versions. You still have to register this webpart and stage the files and object from dev to live. Don't get me wrong, I'm not afraid to write custom code but if you don't need to, why muddy the waters. I've implemented Kentico sites with other CMSs, CRMs, AS400, web services, etc. so it's not that I don't want to write code, I'm thinking why should I when Kentico has already done an awesome job at it!
2. This is an OK solution as well but the last option I'd use (if at all) because a widget is based on a webpart, so in all actuality, you need to create #1 for #2 to work, so if you're not going to do #1, you will never do #2. Right there is enough for me to say no.
3. This is my most favorite approach and most recommended by Kentico and any developer/partner who knows what they are doing with Kentico. Kentico is built around document/page types. If you look at how the content tree and navigation are setup you'll see this approach is not much different than using a static or editable text webpart on a page. Reason I say this is because a "page" (cms.menuitem) is a page type and has essentially the same query as would a custom page type.
The views used in the repeaters select from node, document and page type information, it doesn't matter if the page type is custom or not or if there are static or editable text webparts on a page template. The static and editable text values are stored at the document level but the query still joins the page type, because it has to.
Custom page types allow you to customize your clients experience by giving them one form to enter data on (or multiple different views if you want) and using transformations, display the same data differently all over the site. You (designers and developers) also have control over the rendered HTML and don't need to leave your client try to decide what the site will look like. If that was the case, all sites would look just like the CKEditor styles show...nice brand huh?
By using a custom page type you can also use built-in form controls to gently persuade editors to select or enter data in the format you need or desire. For example, giving the user an image field. You could give them a simple textbox to enter an image url OR you could give them a URL selector OR even better yet, a direct file uploader. This gives them the immediate satisfaction to see the image is uploaded and "it works"!
Creating custom page types to work with templates and shared layouts is the most powerful approach you can use to make your Kentico site. Especially if you know how to use Content Inheritance within your templates. Always start with your wireframes, those are your page layouts. Next incorporate your layouts into templates. The templates use a layout and tell the page where to put the content (webparts and zones). Then if you want to use personalization use widgets on a template. Next add a new page and use your predefined template and start adding content in the content tree. Page sliders, content blocks, news articles, etc. Use the repeater or whatever webpart you need/want to display them.
Using custom page types, you get specific a lot more SEO abilities like page metadata, tagging, categories, friendly URLs, aliases, etc. You don't get this with static or editable text.
4. Assuming static and editable text here for 4 and 5. I perform maintenance on a lot of Kentico sites and many of the early ones are setup with editable and static text webparts on say 3 or 5 templates. This does work and you can get a site out very quick with this but think of the client now when they go to post a new news article or a blog post. Maybe the original developer used the blog template and the blog page type but on the other 35 pages that have latest articles or blog posts, they are all static text. Now not only does the blog editor enter their new post, they have to update 35 other pages with static text.
Don't get me wrong, the above is a pretty extreme example (but it exists, I've fixed many) and it does work BUT in the end your client will be very unhappy with you after they make the first few edits and you lose their business. OR you gain more business (yes!) to fix what you implemented wrong in the first place, in which, you should feel horrible that you cheated your client but if you have no morals or values, no big deal...right?
5. See answer #4
#4 and 5 are useful and every now and then I use them simply for fillers if the client is unsure of what the data structure might be.
Now on to your other points:
Cost vs. time:
You get what you pay for. If the client has a lopsided project management triangle and has no budget then so be it, you need to find a way to work with that. If that means not taking the job (no matter how big the name is), you have to remember your name (personal and business) and reputation is on the line. If you deliver an inferior product and your client is unhappy, others will find out, just give it time...
Now on the flip side, if you are honest up front and state "hey here is what you get for this time, but if we had a bit more time to use all the features of Kentico, and you'd get THIS! WOW!", I can guarantee the majority of the clients will take a deep look into their budget for that extra time because it makes their life easier and that's why they spent the money on a Kentico license.
If a client wants me to deliver an inferior product, I won't take the business. Not because I don't agree with them or won't do the work or couldn't use the money to feed my 4 kids. It's about my morals and beliefs as a person and a business professional. It's not about a quick buck and a client, its about earning my client's trust and repeat business.
Promoting changes:
If a client has an environment where they can afford a dev or staging environment then, there is no question, do it right the first time. Kentico offers content staging, which allows you to bidirectionally sync changes between environments. Yes this is only available with Ultimate and EMS licenses but its a feature and if the client is looking for this, then it's worth it. You can also export and import changes manually. Another option would be to manually recreate the content or object.
Typically when a client has 2 or more environments, I always do server coding or major template changes on dev just to be safe. Any content related items, adding/removing pages, updating pages, new forms, etc. I'll do those on the live site and implement workflow. This allows for the "simple" changes to be done immediately while the other more complex items (new templates or layouts and doc types) can be tested on the dev site without breaking anything. Then when you are finished creating those objects, export them and import them into live. You can then start adding your content and it displays on your page.
I base my answer off of the majority of the sites I build. I ALWAYS use Portal development mode with custom webparts and modules (if needed). I never use straight ASPX or MVC simply because they do not allow my clients to utilize the features of the Kentico. Yes they are powerful and you can develop quickly them, but if you took a day or two and learned about how to develop in Portal mode, you'd see the same thing I do, no need for ASPX or MVC (IMHO, they're only there for developers who don't want to learn).
Hopefully my lengthy answer helps out a bit. I hope others chime in as well because this is a very valid topic and discus it all the time with other developers.
Best of luck!
Brenden