I wouldn't use portal_view_customisations as it makes it hard to upgrade later. Instead, in your diazo theme, define a rule which changes checked attribute. If you have no diazo theme enable, its easy to add a theme which lets all the html go through unchanged, except that change.
Just to be clear, @djay raises a good point in that if you customize any template you have to check if they changed and update accordingly when you upgrade your Plone version.
However beware that transferring customization work to the Diazo layer may bring comparable downsides. Basically instead of a bunch of templates to diff and update you may end up with a very extensive and hard to maintain rules.xml, which after a not so distant point drastically decays performance. Once I got into a project in which new developers were hating Plone because it was so slow. They were doing all customizations at Diazo layer, on a per section base, including multiple xi:includes and conditional HTMLs (since it was cumbersome to have multiple developers working in different sections of the same files). It was terrible, specially on development mode when all of these get recompiled at every request.
All in all I guess it depends on your usecase and taste. Mine is to keep rules.xml as simple (no xslt) and as short as possible (one more reason: Diazo debugging is hard). I try to make rules worry only about theming and prefer to control which information is shown at template level. But if the site won't grow much/you don't have too many rules in the horizon, Diazo may indeed serve you better.
@davilima6 Yes, its easy to create badly performing rules such as using xpath // too much. It would be nice if plone gave you warning when rules increase request time significantly. Also rules do break silently if the content html has changed in ways your rules don't expect. Again it would be nice if plone provided ways create tests for your diazo. Wither either template overrides or diazo you need to document what your customisation is intending to achieve to make it more maintainable.
Overall I think diazo wins in terms of learning curve. Determining which template to override is way harder, and template overrides often require learning both TAL and python. Diazo for us, has been easier to teach to non developers. Of course, you can do more with templates, so developers will tend to prefer it.
You can't just modify only a small part of the template. You have to override of the whole template, and if you ever upgrade, or come across another plugin that also wants to override that template, then you have to be aware and mange this process yourself. You are effectively reaching in and messing with the innards of plone rather than using a more stable api.