You can pretty much use any design you like.

The FX property pattern gives you a lot of functionality: it creates observable, writable, properties that in many cases can be wired directly into controls. So if you design your "table beans" using that pattern, then you can use the PropertyValueFactory as your cellValueFactory, and lots of stuff happens "automagically", such as updating table cells when the value changes, and vice-versa.

Using properties themselves doesn't add much overhead. There's a nice document that outlines some good practices for using FX properties.

The PropertyValueFactory, though, I think does add some overhead, as it relies on reflection to find the property from a specified name. So you will see some (I don't promise how much) benefit if you replace

myTableColumn.setCellValueFactory(new PropertyValueFactory<>("thing"));

with

myTableColumn.setCellValueFactory(new Callback<CellDataFeatures<S,T>, ObservableValue<T>>() {
    public ObservableValue<T> call(CellDataFeatures<S,T> data) {
        return data.getValue().thingProperty() ;
    }
});

(or, in Java 8, the much simpler

myTableColumn.setCellValueFactory(data -> data.getValue().thingProperty());

).

Now, if you don't need the bells and whistles of the JavaFX properties (for example, the values in the table row items won't be changed external to editing in the table, and the editing in the table needs to be "hard-wired" via a setOnCommit(...) anyway), then you can save the (small) overhead of the JavaFX properties by omitting them and just using the regular Javabean model, with getX() and setX(...) methods. There's some, though I think not much, performance benefit, and obviously less code.

The overhead from the reflection in the PropertyValueFactory is (my guess) larger than the overhead from using JavaFX properties, so if you're looking to do this for performance reasons, I would also explicitly wire the callback to the get method, instead of relying on the PropertyValueFactory. As in the link in @brian 's comment, some previous versions were highly inefficient in implementing that (though this is now fixed). So something like

class Item {
  private String name ;
  public String getName() {
    return name ;
  }
  public void setName(String name) {
    this.name = name ;
  }
}

TableColumn<Item, String> nameCol = new TableColumn<>("Name");
nameCol.setCellValueFactory(itemData -> new ReadOnlyStringWrapper(itemData.getValue.getName()));

is probably about as efficient as it gets: again though, if you want your table editable, you need to wire editing commits to calls to setName(...) by hand, and updates to the data external to the table won't be reflected in the table.

Bottom line: if you don't want to use JavaFX properties, you don't have to. You miss some free functionality, and there are ways to code that in yourself, and you might get some (slight) performance benefit as well as saving some code. The one case that's really hard to work around is updating properties displayed in the table, externally from table editing. If you are doing that in your code, JavaFX properties make your life a lot easier.

Update: Based on your comments, I would recommend using JavaFX properties for your use case. I strongly recommend reading the document linked above, slides 18-46, and especially the property patterns on slides 30-43.

In particular, though, use the abstract class (e.g. StringProperty) as the type for your property, not the concrete type (SimpleStringProperty), and when using properties as properties of objects, instantiate them with a name and reference to their bean. For example:

private StringProperty referenceNumberProperty = new SimpleStringProperty(this, "referenceNumber");
public final StringProperty referenceNumberProperty() {
    return referenceNumberProperty ;
}
public final String getReferenceNumber() {
    return referenceNumberProperty.get() ;
}
public final void setReferenceNumber(String referenceNumber) {
    this.referenceNumberProperty.set(referenceNumber);
}

Note that it's marginally more conventional not to include "property" as part of the reference name (i.e. private StringProperty referenceNumber instead of private StringProperty referenceNumberProperty), but of course that's totally up to you.