Q:

If I'm going to delete a shared branch, is it OK to rebase? 

Say I have two branches - master and feature.  feature is pushed to origin and multiple developers are working on.  All developers have finished their work, committed it and pushed to the shared branch.  I pull all changes into my local checkout of feature so it's up to date. 
I run git merge-base master feature and it gives me 433c4d34e86c3997ffc0ab1b42bb27acce09b2a6. 
I want to make this just one commit, so I run git rebase -i 433c4d34e86c3997ffc0ab1b42bb27acce09b2a6.  For the first commit I use reword and for the rest I use fixup.  The rebase finished and, as expected, it tells me my branch and origin/feature have diverged.  I don't push. 
I git checkout master then git pull and finally git rebase master feature.  Finally, I git checkout master again then git merge feature. 
git status now tells me:
# On branch master
# Your branch is ahead of 'origin/master' by 1 commit. 
#
nothing to commit (working directory clean)

At this point, is it safe to push to origin?  Bearing in mind the feature branch will be deleted and never used again so we're not worried about other devs having their history rewritten from that point of view. 
Or am I missing something else here as to why this is bad?  Maybe a better way of doing it altogether? 

A:

I think there are two points of confusion here. 
First, it sounds like you're concerned about the general advice to never rebase a branch that's been pushed, but you aren't sure if you understand the reason for that advice. 
The potential that other developers will have to clean up the state of their copy of the branch is the reason for this guideline; and so a better form of the advice is, if you want to rebase a branch that has been pushed/shared with others, you need the agreement of everyone who has a copy of the branch. 
If everyone agrees that they're not doing any more work on feature, and that all work done on feature has been pushed already, and that they're just going to delete feature; then there's no extra work created for anyone by rebasing feature, and nobody should have a problem with it. 
But even that doesn't matter, because you've described a situation where you are getting ready to push master.   The above only applies if you're going to push feature... and why would you do that, if it's just a branch you're deleting anyway?   If anything you would locally delete feature and push the delete. 
So I assume you think there's some internal relationship between a branch and the commits that the branch either can reach now, or could in the past.   There isn't.   The fact that the commit you want to push to master came from a rebase of feature has no meaning to git.   It's still just a new commit on master. 
(Which draws attention to another point: you've taken the long way around by doing an interactive rebase.   Maybe the intent was to manipulate the default commit message or something?   But if you want to apply all the changes from feature in a single commit to master, the easiest thing is
git checkout master
git merge --squash feature

which, just like your procedure, can sometimes cause headaches but is usually fine if you're just going to discard feature anyway.)